Re: the limits of crypto and authentication

2005-07-19 Thread Jaap-Henk Hoepman

Only problem is that cell phones have become so utterly complex (hosting
several processors and a plethora of software components) that it will never
become the trusted device that we once thought it could be...

Personal it is though

Jaap-Henk

On Sat, 09 Jul 2005 18:56:22 -0700 James A. Donald [EMAIL PROTECTED] writes:
 --
 Ian Grigg [EMAIL PROTECTED]
 In the payments world we've known how to solve all 
 this for some time, since the early 90s to my
 knowledge. The only question really is, have you got a
 business model that will pay for it, because any form
 of token is very expensive, and the form of token that
 is needed - a trusted device to put the application,
 display, keypad and net connection on - is even more
 expensive than the stop-gap two-factor authentication
 units commonly sold.

 Such a device sounds like a cell phone.


 --digsig
  James A. Donald
  6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
  5nMEZ3YWGEUKZWzEprv/E7vI+8j9jzBNX8GWiJiO
  4nb4BSDrVGLfq42fHktPRSAfFO3N0uGBnezGRNWrS


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


-- 
Jaap-Henk Hoepman   |  I've got sunshine in my pockets
Dept. of Computer Science   |  Brought it back to spray the day
Radboud University Nijmegen |Gry Rocket
(w) www.cs.ru.nl/~jhh   |  (m) [EMAIL PROTECTED]
(t) +31 24 36 52710/53132   |  (f) +31 24 3653137


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


Re: the limits of crypto and authentication

2005-07-19 Thread Jaap-Henk Hoepman

Actually, Dutch banks already give users the option to recieve one-time
pass-codes by SMS to authenticate internet banking transactions (instead of
sending a list of those codes on paper by ordinary mail in advance). So it's
less unrealistic than you think.

Jaap-Henk

On Sat, 09 Jul 2005 20:38:38 +0200 Florian Weimer [EMAIL PROTECTED] writes:
 You send the pass code in an SMS to the user's mobile phone, together
 with some information on the transaction.  (If the SMS delay is a
 problem, use a computer-generated phone call.)  The pass code is then
 entered by the user to authorize the transaction.

 This will eventually break down, once PCs and mobile phones are
 integrated tightly, but in the meantime, it's reasonably secure even
 if the client PC is compromised.

 I'm not sure if users will accept it, though.  What's worse, the costs
 for sending the SMS message (or making the phone call) are so
 significant that it's unrealistic we'll see widespread use of such
 technologies.

 (Manually transferring cryptographic tokens which depend on the
 transaction contents seems to be infeasible, given the number of bits
 which must be copied.)

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



-- 
Jaap-Henk Hoepman   |  I've got sunshine in my pockets
Dept. of Computer Science   |  Brought it back to spray the day
Radboud University Nijmegen |Gry Rocket
(w) www.cs.ru.nl/~jhh   |  (m) [EMAIL PROTECTED]
(t) +31 24 36 52710/53132   |  (f) +31 24 3653137

--


-- 
Jaap-Henk Hoepman   |  I've got sunshine in my pockets
Dept. of Computer Science   |  Brought it back to spray the day
Radboud University Nijmegen |Gry Rocket
(w) www.cs.ru.nl/~jhh   |  (m) [EMAIL PROTECTED]
(t) +31 24 36 52710/53132   |  (f) +31 24 3653137


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


Re: the limits of crypto and authentication

2005-07-19 Thread Anne Lynn Wheeler
ref:
http://www.garlic.com/~lynn/aadsm20.htm#10 the limits of crypto and
authentication
http://www.garlic.com/~lynn/aadsm20.htm#15 the limits of crypto and
authentication
http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and
authentication

one of the issues raised in the x9.59 business rule case was whether
there are sufficient PANs (account numbers) to be able to temporarily be
able to issue two PANs for every account; one PAN useable against
account in X9.59 transactions and one PAN useable against account in
non-X9.59 (legacy, non-authenticated) transactions.

there was some issues raised about having multiple PANs pointing at the
same account ... but that is in wide-spread use already as normal
business practice.

Note that during any transition to secure x9.59 transaction ... the
worst case scenario is that there would be two PANs in existance for
every account. The issue raised whether the account number space is
large enuf to have two PANs for every account (note that if this turns
out to be a real issue ... it would also be a much larger problem for
one-time-PAN implementations ... where you might have hundreds of PANs
mapped to the same account number).

The problem for an X9.59 transition is actually somewhat less severe.
Part of the current PAN strategy is stacked against re-use of a PAN.
However, in the x9.59 transition case, I would claim that PAN re-use is
much less of a problem

1) re-use of any PAN for x9.59 use  automatically disables the PAN
for all non-x9.59 use (if the PAN had some lingering legacy attachment
... that woulc be disabled as soon as it was assigned for x9.59 use)

2) re-use of a previously assigned x9.59 PAN for x9.59 use ... could
happen on somewhat accelerated schedule ... since the previous x9.59 PAN
use would have been associated with a public key that was no longer active.

the lingering issue as dangling business process associated with old
transactions that are bound to a specific PAN. re-use of PANs need to
after any such dangling business processes have been assured to have
expired.

the upside is that any transition to x9.59 would then give the consumer
some choice and/or control ... strict use of x9.59 transactions would
give the consumer some protection against most skimming, havesting and
data breach threats and vulnerabilities. such a consumer might then want
any non-x9.59 PANs to have very strict use limits (akin to some of the
customer specified limits available on pin-debit accounts ... or what is
available on dependent cards).

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


Re: the limits of crypto and authentication

2005-07-19 Thread Anne Lynn Wheeler
Jaap-Henk Hoepman wrote:
 Actually, Dutch banks already give users the option to recieve one-time
 pass-codes by SMS to authenticate internet banking transactions (instead of
 sending a list of those codes on paper by ordinary mail in advance). So it's
 less unrealistic than you think.

there is also the EU bank challenge/response scenario (requires two-way
communication protocol chatter). the customer initiates a transaction
... on the internet or even over (voice) phone. the bank responds with a
challenge which is entered into a calculator sized device and the
display comes back with the response. the response then is either typed
or the keyboard (or the phone keypad).

basically it is a relatively dumb pin-pad sleave that a chipcard slips
into ... some old post visiting the company that makes the devices:
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking

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


Re: the limits of crypto and authentication

2005-07-16 Thread Anne Lynn Wheeler
Anne  Lynn Wheeler wrote:
 But SET Lite and MOSET critically alter the SET 1.0 architecture and
 soften SET's rock-hard security - all for the sake of convenience. For
 example, the technologies abandon the idea that each online consumer is
 going to have a bank-issued SET digital certificate for credit-card
 encryption. This certificate was to be the main means of verifying the
 consumer's real identity on the Internet.

note that the bank-issued consumer SET digital certificate ... wasn't
used for credit-card encryption. the original set had this terribly
convoluted process where the consumer encrypted some of the stuff with
the *merchants* public key and other stuff with the *processors* public
key.

the consumers relying-party-only digital certificate
http://www.garlic.com/~lynn/subpubkey.html#rpo

was used for the client to perform something you have authentication
... aka digitally signing with the corresponding private key (aka the
verification of the digital signature implies that the signer has access
and use of the private key)

since it wasn't an x.509 identity certificate, didn't contain any
personal information, and was purely a relying-party-only certificate
... there was no real identity on the internet (avoiding raising
horrible privacy and liability issues).

futhermore, since it was a simple relying-party-only certificate, it is
trivial to demonstrate that it is redundant and superfluos ... aka just
flow the transaction thru to the consumer's bank ... and they can
validate the digital signature using the onfile public key. it isn't
necessary for the consumer to repeatedly append a relying-party-only
certificate to possibly thousands of transactions ... for transmission
back to the issuing institution ... which has the original *onfile*;
especially when the redundant and superfluous relying-party-only
certificate can represent a payload bloat of one hundred times.

note that the referenced article is dated 1999/3/22 and references the
original SET 1.0 deployment (full blown redundant and superfluous
relying-party-only customer certificates) two years earlier (spring
1997). The draft 1.0 specification had appeared spring 1996, initial
prototype appeared early fall 1996, and dedicaed demo systems showed up
at floor shows by the end of 1996.

the other reference indicates that browsers with ssl support appeared
late 1994 with big announcement the spring of 1995.
http://www.garlic.com/~lynn/aadsm20.htm#12 the limits of crypto and
authentication

a trivial side-note ... since the SET specification wasn't issued by a
sanction standards body ... it wasn't a Standard in the official sense.

one of the operational differences between SET and x9.59 financial
industry standard ...
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#privacy

is that x9.59 has an operational rule that account numbers used in x9.59
transactions can't be valid in non-x9.59 transactions  which
eliminates the requirement for horrendous amounts of cryptography as
countermeasure for evesdropping of transactions during transmission
(since evesdropping of the transactions doesn't provide an attacker with
sufficient information to perform fraudulent transactions). As a
by-product, it also eliminates the threats and vulnerabilities from
data-breaches ... where there is sufficient information in logged
transactions for a crook to perform fraudulent transactions.

In the SET scenario ... even when the transaction is authenticated using
digital signature ... there was still a requirement for horribly complex
cryptographic implementation as countermeasure to attacker evesdropping
the transaction and using the gained information to perform fraudulent
transactions.

There is an issue where both account fraud and identity fraud have been
lumped under global identity theft label. In the strict account fraud
case, the attacker just needs to obtain sufficient information to
perform fraudulent transactions (against existing accounts) w/o
necessarily obtaining any real personal information.

While SET avoided the horrible privacy and liability issues with real
x.509 identity certificates by using relying-party-only certificates ...
it was still subject to account fraud where crooks obtaining access to
information from transaction (either *data-in-flight* or *data-at-rest*
 aka data breaches) have access to sufficient information for
performing fraudulent transactions.

In contrast, x9.59 is signifcantly simpler and represents significantly
lighter payload ... and even eliminates the need to provide security
confidentiality for transactions as countermeasure against attackers
(both in the *data-in-flight* as well as the *data-at-rest* cases)
looking at performing account fraud transactions.

past posts mentioning x9.59  business rules:
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsm7.htm

Re: the limits of crypto and authentication

2005-07-15 Thread Rich Salz
 If you had two products ... both effectively performing the same
 function, one you already had deployed, which was significantly cheaper,
 significantly simpler, and significantly faster, which one would you choose?

I was told that one of the reasons SSL took off was because Visa and/or MC
told merchants they would for the time being treat SSL as card-present,
in terms of fraud penalties, etc.  If this is true (anyone here verify?
My source is on the list if s/he wants to name themselves), then SSL/SET
is an interesting example of betting on both sides.
/r$
-- 
Rich Salz  Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html


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


Re: the limits of crypto and authentication

2005-07-15 Thread Aram Perez

On Jul 14, 2005, at 8:13 PM, Rich Salz wrote:


If you had two products ... both effectively performing the same
function, one you already had deployed, which was significantly  
cheaper,
significantly simpler, and significantly faster, which one would  
you choose?


I was told that one of the reasons SSL took off was because Visa  
and/or MC
told merchants they would for the time being treat SSL as card- 
present,
in terms of fraud penalties, etc.  If this is true (anyone here  
verify?
My source is on the list if s/he wants to name themselves), then  
SSL/SET

is an interesting example of betting on both sides.


On the contrary, merchants were (and maybe still are) being charged  
MOTO (mail order/telephone order) rates for using SSL. Even SET was  
going to charge MOTO rates until just before it was finalized. The  
payment card companies weren't getting enough interest for SET and  
decided to offer card-present rates to get more interest in SET. SSL  
took off because it was free, in over 90% of the browsers (Netscape  
own the browser market then), and it was easy to integrate into  
shopping carts. As a merchant, basically your only cost was your  
VeriSign cert.


But you are correct in that the payment card companies were in an  
interesting position: on one hand they charge higher rates for using  
SSL but on the other hand, the perception was that something more  
secure than SSL was needed.


One other point, SET did NOT require certs for the consumers. The  
client-merchant protocol supported clients without certs.


Respectfully,
Aram Perez


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


Re: the limits of crypto and authentication

2005-07-15 Thread Anne Lynn Wheeler

Rich Salz wrote:

I was told that one of the reasons SSL took off was because Visa and/or MC
told merchants they would for the time being treat SSL as card-present,
in terms of fraud penalties, etc.  If this is true (anyone here verify?
My source is on the list if s/he wants to name themselves), then SSL/SET
is an interesting example of betting on both sides.


I only know of MOTO ... the original netscape e-store and merchants 
processed thru the original payment gateway.

http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

SSL originally just provided for webserver authentication. while we 
mandated mutual authentication for SSL between webservers and the 
payment gateway (before there was even a specification for mutual 
authentication). Information about the respective other end-point were 
preloaded in the respective servers ... so the use of digital 
certificates was purely an artificial artifact of the existing code base.


However, normal merchant webserver operation for SSL was purely 
one-sided authentication ... there was no form of client authentication 
that would provide any kind of basis for either cardholder-present or 
card-present.


There is something for being there first, starting late 94 ...
http://scout.wisc.edu/Projects/PastProjects/NH/95-03/95-03-27/0016.html

remember what Verisign was called before it was renamed Verisign?

SET prototype shows up early fall 96 with dedicated demo systems 
appearing at conferences late '96 (dedicated demo systems taking 30 
seconds elapsed time to perform transaction).


Two of the major risks and vulnerabilities that have been discussed are 
evesdropping on data-in-flight ... and data breaches at merchant 
databases ... old post on security proportional to risk

http://www.garlic.com/~lynn/2001h.html#61

both SSL and SET addressed confidentiality of data-in-flight. Neither 
SSL nor SET addressed data breaches at merchant databases.


Going on in parallel with webservers doing MOTO transactions thru the 
payment gateway  you also found some number of webservers doing 
emulated POS terminal dialup operations (also MOTO transactions). Some 
number of vendors were peddling software that was originally developed 
to run on PCs and autodial merchant processor (effectively emulated POS 
terminal dial) ... software originally targeted for hotels, casinos, etc.



... from long ago and far away:

Date: Sat, 24 Feb 1996 17:08:01 -0500 (EST)
From: H Morrow Long [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Draft SET Standard/specs now online at MC and Visa

The new SET (Secure Electronic Transaction) draft standard/
specs are now online at VISA and Mastercard for downloading.

The draft docs were just released yesterday (Feb 23).

The docs are available in Word and Postscript file formats
for Windows, Unix and the Mac.

Check out:

http://www.mastercard.com/set/set.htm
http://www.visa.com:80/cgi-bin/vee/sf/standard.html?2+0

The Web pages also have information on how to subscribe to
the set-discuss mailing list.

- Morrow


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


Re: the limits of crypto and authentication

2005-07-15 Thread Ben Laurie

Perry E. Metzger wrote:

Ben Laurie [EMAIL PROTECTED] writes:


Perry E. Metzger wrote:


Anonymity is a concern to me, too, but I suspect that it is hard to
get anonymity in a credit card transaction using current means, even
if the merchant isn't online. Pseudonymity, perhaps.


Can we not aim higher than merely doing as badly as current systems do?



I think that by eliminating the need for a merchant to learn
information about your identity I have aimed higher. Given that we're
talking about credit instruments, however, it may be difficult to
eliminate the need for the issuer to track transactions. However,
given the way I've described the protocol, it would be possible to use
a variant on it for digital cash purses without the merchant being
impacted. It isn't clear to me, though, who would issue such things in
the current environment.


You never know who might do stuff if its easy for them to do so. Make it 
hard, and you can be more confident they won't.


But I'm glad to hear we're not in opposition on this.

Cheers,

Ben.

--
ApacheCon Europe   http://www.apachecon.com/

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]


Re: the limits of crypto and authentication

2005-07-15 Thread Anne Lynn Wheeler
a harder problem for early stage web merchants was getting a merchant
financial institution  the merchant financial institution that
sponsors a merchant for payment transactions ... takes financial
responsibility for that merchant.

the standard procedure was to send somebody out to the retail
brickmorter and do an asset inventory ... to see if the merchant went
under ... that there would be enuf assets left to help cover the
merchant financial institutions losses.

retail web merchants might have nearly zero assets ... they leased time
with a webhosting and fulfillment was outsourced ... so there was no
onhand inventory and effectively no assets. if they were totally
unsuccesful ... then the merchant financial institution would have
little outstanding transaction financial liability.

there were cases where merchant financial institution would try and
cancel a merchant as it became succesful ... since the outstanding
transaction liability for the merchant financial institution could be
going way up ... with no increase in assets to cover the finanical
institution's outstanding liability.

for such high risk merchants ... the merchant financial institution
discount might actually be bigger than the MOTO discount ... or any
difference between MOTO and card-present.

early web merchants tended to be existing brickmorter operations where
web MOTO (mail-order/telephone-order) transactions were not separated
out from non-web MOTO transactions.

there were all sorts of strategy meetings in the '95 time-frame, brain
storming about how to get a bank's financial risk department to even
approve purely web merchant signup (and MOTO vis-a-vis card-present
wasn't a primary issue).

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


Re: the limits of crypto and authentication

2005-07-15 Thread Ram A Moskovitz
On 7/14/05, Anne  Lynn Wheeler [EMAIL PROTECTED] wrote:

remember what Verisign was called before it was renamed Verisign?
Digital Certificates International, Inc. 

Did you consult for First Data Corp. at the time?



Re: the limits of crypto and authentication

2005-07-15 Thread Anne Lynn Wheeler
Aram Perez wrote:
 One other point, SET did NOT require certs for the consumers. The 
 client-merchant protocol supported clients without certs.

there was a later set-lite w/o certs for clients ... but the original
specification had client certs as part of the core process.

note that the SET consumer certificate was *NOT* a x.509 identity
certificate ... because of stated reasons regarding privacy and
liability. It was a relying-party-only certificate that basically
contained the account number and the public key
http://www.garlic.com/~lynn/subpubkey.html#rpo

It was also, not a true PKI ... since it didn't have any certificate
administration and management infrastructure. It was purely a
*certificate manufactoring* process (a term we had coined to
differentiate the early SSL certificate operations from what had been
defined for a PKI operation). Further, the statement was that they could
get by w/o a PKI operation ... since it was purely a certificate
manufactoring process using relying-party-only certificates (containing
just the public key and account number), the business process could be
managed by deactivating the account number in the *real*, real-time,
online operation.

quicky search engine for set-lite:
http://iugsun.cs.uni-dortmund.de/lehre/datenschutz/material/folien/dsss2004-5-ecommerce.pdf
http://www.it.murdoch.edu.au/~smr/honours/admin/info/DavidsProposal.html
http://www.indiainfoline.com/bisc/ieps.html
http://www.networkworld.com/archive/1999/61423_03-22-1999.html

from above:

When MasterCard and Visa unveiled technology for secure Internet
electronic commerce transactions two years ago, they thought it would
take over the world.

But while Secure Electronic Transaction (SET) has made inroads in Europe
and Asia, it has faltered badly in the U.S. Faced with technical and
business obstacles to SET, MasterCard and Visa are now coming up with
alternatives to SET - SET Lite and Merchant-originated SET (MOSET).

But SET Lite and MOSET critically alter the SET 1.0 architecture and
soften SET's rock-hard security - all for the sake of convenience. For
example, the technologies abandon the idea that each online consumer is
going to have a bank-issued SET digital certificate for credit-card
encryption. This certificate was to be the main means of verifying the
consumer's real identity on the Internet.


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


Re: the limits of crypto and authentication

2005-07-15 Thread Anne Lynn Wheeler
Ram A Moskovitz wrote:
 Did you consult for First Data Corp. at the time?

some reference:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

little later, we got to review chaum and brand stuff. brand had done a
take-off on chaum's stuff so that if somebody double-spent (aka fraud)
... the financial institution could determine who did it (basically a
form of solving two equations in two unknowns).


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


Re: the limits of crypto and authentication

2005-07-14 Thread Rich Salz
 I think that by eliminating the need for a merchant to learn
 information about your identity I have aimed higher. Given that we're
 talking about credit instruments,

Wasn't that a goal of SET?

/r$

-- 
Rich Salz  Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html


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


Re: the limits of crypto and authentication

2005-07-14 Thread Perry E. Metzger

Rich Salz [EMAIL PROTECTED] writes:
 I think that by eliminating the need for a merchant to learn
 information about your identity I have aimed higher. Given that we're
 talking about credit instruments,

 Wasn't that a goal of SET?

Some of it was, yah. I don't claim that any of this is original. The
problem with SET was that the protocol was far too complicated to
implement (hell, the spec was nearly too heavy to lift), and it was
proposed well before people even had USB connectors on their
computers, let alone cheap USB card interfaces. I think people threw
out the baby with the bathwater, though. The general idea was correct.


Perry


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


Re: the limits of crypto and authentication

2005-07-14 Thread Anne Lynn Wheeler
Rich Salz wrote:
 Wasn't that a goal of SET?

there was an observation that SET possibly wouldn't divulge your account
number until the merchant had been determined to be some entity
registered as a merchant (akin to the SSL domain name infrastructure
certificates ... if a spoofed site didn't use SSL until you hit the
pay/checkout button, what is the probability that the spoofed site
provide a URL that matched some valid certificate that they did have).

note, however, some of the participants even got confused about this issue.

note that there are a lot of merchant business processes that require
the account number ... and therefor you can't prevent the merchant from
possessing the account number. some might be tempted to observe that
there is a kind of conflict of interest ... using the same value for
authentication purposes as well as widely needed for a large number of
other purposes (akin to designing a system that widely uses your userid
a basis for normal functioning ... as well as making your userid also
your password).

some past posts where the SET issue of divulging account number was
disucssed.
http://www.garlic.com/~lynn/2001h.html#38 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#39 Credit Card # encryption
http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re:
crypto flaw in secure mail standards

I thot the goal of SET was to maximize the number of RSA-ops being
executed in the world.

When I first obtained a copy of the initial SET specification, I did a
RSA-ops profile and a business operation profile. An acquatance had done
some work on the BSAFE library and improved the performance by a factor
of four times. I got him to run timing tests on the SET RSA-ops profile
across a number of different machines. I then communicated the results
to a number of people that were part of the SET group. The reply from
various members of the SET group was that the numbers were obviously one
hundred times too slow (the correct answer should have been that the
numbers were four times too fast). Six months later when the first
prototype SET code was running ... their measured numbers were within a
couple percent of my earlier profile numbers (aka the BSAFE enhancements
had been given back to RSA).

One possible observation was that SSL work
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

was already providing account number confidentiality for
*data-in-flight*.  The significantly much more complex, and heavyweight
SET would have needed to provide countermeasures for significantly more
threats and vulnerabilities ... like security for *data-at-rest* (aka
data breaches) in order to make any headway against the (SSL) incumbant.

I also made a couple comments to the SET group about the heavy-weight
nature of SET (apparently the RSA-ops being one hundred times more
onerous than they had anticipated). Effectively, the SET RSA-op profile
was symmetrical  but the standard processing is quite asymmetrical.
In effect, the massive datacenters that are currently processing credit
card transactions would have needed their computational facilities
increased by at least one hundred times (SET RSA-op profile was looking
at tens of seconds per transaction while many of these datacenters
measure their thruput in thousands of transactions per second ... a four
orders of magnitude gap).

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


Re: the limits of crypto and authentication

2005-07-14 Thread Aram Perez

On Jul 14, 2005, at 6:23 AM, Perry E. Metzger wrote:


Rich Salz [EMAIL PROTECTED] writes:


I think that by eliminating the need for a merchant to learn
information about your identity I have aimed higher. Given that  
we're

talking about credit instruments,


Wasn't that a goal of SET?


Some of it was, yah. I don't claim that any of this is original. The
problem with SET was that the protocol was far too complicated to
implement (hell, the spec was nearly too heavy to lift), and it was
proposed well before people even had USB connectors on their
computers, let alone cheap USB card interfaces. I think people threw
out the baby with the bathwater, though. The general idea was correct.


While the SET protocol was complicated, it's failure had nothing to  
do with that fact or the lack of USB on PCs. You could buy libraries  
that implemented the protocol and the protocol did not require USB.  
IMO, the failure had to do with time-to-market factors. In the late  
90s, when ecommerce was just at it's infancy and you took the risk of  
setting up a web store, were you going to wait you could integrate a  
SET toolkit into you web site and until your customers had SET  
wallets installed on their PCs before selling a product? Or were you  
going to sell to anyone who used a web browser that supported SSL? It  
was very simple economics, even if you had to pay VeriSign $400 for  
your SSL certificate and pay Visa/MasterCard a higher fee.


Respectfully,
Aram Perez


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


Re: the limits of crypto and authentication

2005-07-14 Thread Amir Herzberg

Pat Farrell wrote:

On Wed, 2005-07-13 at 23:43 -0400, Rich Salz wrote:


I think that by eliminating the need for a merchant to learn
information about your identity ...


Wasn't that a goal of SET?


As I recall, the goal of SET was to have a standard
that was not invented by CyberCash. (I may be biased, I
worked at CyberCash at the time).
This is incorrect. The main politics around SET was the artificial 
`merger` of iKP (from IBM  Mastercard) and STT (from Visa and MS). As 
far as I remember, CyberCash were involved but choose not to. They also 
did not disclose their protocol like the other proposals. I may be wrong 
about the CyberCash role, though, it was a while, and I don't think it 
matters so much...

--
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI: 
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages: 
http://AmirHerzberg.com/shame


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


Re: the limits of crypto and authentication

2005-07-14 Thread Pat Farrell
On Thu, 2005-07-14 at 18:43 +0200, Amir Herzberg wrote:
 Pat Farrell wrote:
  
  As I recall, the goal of SET was to have a standard
  that was not invented by CyberCash. (I may be biased, I
  worked at CyberCash at the time).

 This is incorrect. The main politics around SET was the artificial 
 `merger` of iKP (from IBM  Mastercard) and STT (from Visa and MS). As 
 far as I remember, CyberCash were involved but choose not to. They also 
 did not disclose their protocol like the other proposals. I may be wrong 
 about the CyberCash role,

CyberCash protocols were defined in RFCs. The RFCs
are probably still out there, altho no longer in use.
The other two protocols were defensive against CyberCash
and it looked like there would be three non-interoperative
protocol suites. The invention of SET was a marriage of
convience. CyberCash had 15000 merchants, it isn't important now,
but I'd love to know the number of non-pilot SET merchants
in the wild.

I was the project manager for CyberCash's project implement
SET as a joint venture with Netscape, Toshiba and Visa.
And I wrote the crypto code.

At one of the early SET committee meetings, someone from
CyberCash proposed that SET simply use the RFC'd protocols.
I expect that the offer was not made with proper political
tact.

As others have said, and in the spirit of the subject
of this thread, SET failed for many reasons, many
of them economic. There was little effort made
to bribe the merchants, I think there was talk of
a 26 basis point change in the discount rate,
which the banks thought was huge and the merchants
thought was noise. What really killed it
was the billions it would have cost all
the banks to issue and manage all the
certificates.

The crypto in SET was fine. The use of
certificates was excessive but in line with
PKI thinking of the time.

The problem was that it was a very expensive sledge hammer
to kill a flea.

In retrospect, there was over reliance on crypto and
confusion of identity and authentication
contributed, but others were making the same
mistake.

We just have to be smarter now, nearly a decade later.
Crypto has to solve business problems that masses of
real people have.


-- 
Pat Farrell
http://www.pfarrell.com



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


Re: the limits of crypto and authentication

2005-07-14 Thread Perry E. Metzger

Aram Perez [EMAIL PROTECTED] writes:
 While the SET protocol was complicated, it's failure had nothing to
 do with that fact or the lack of USB on PCs. You could buy libraries
 that implemented the protocol and the protocol did not require USB.
 IMO, the failure had to do with time-to-market factors. In the late
 90s, when ecommerce was just at it's infancy and you took the risk of
 setting up a web store, were you going to wait you could integrate a
 SET toolkit into you web site and until your customers had SET
 wallets installed on their PCs before selling a product? Or were you
 going to sell to anyone who used a web browser that supported SSL? It
 was very simple economics, even if you had to pay VeriSign $400 for
 your SSL certificate and pay Visa/MasterCard a higher fee.

You are perfectly right on this. I oversimplified and distorted.

Still, I suspect that while the time was not right for SET back then,
the time may nearly be right for better things now.

Perry

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


Re: the limits of crypto and authentication

2005-07-14 Thread Anne Lynn Wheeler
Aram Perez wrote:
 While the SET protocol was complicated, it's failure had nothing to  do
 with that fact or the lack of USB on PCs. You could buy libraries  that
 implemented the protocol and the protocol did not require USB.  IMO, the
 failure had to do with time-to-market factors. In the late  90s, when
 ecommerce was just at it's infancy and you took the risk of  setting up
 a web store, were you going to wait you could integrate a  SET toolkit
 into you web site and until your customers had SET  wallets installed on
 their PCs before selling a product? Or were you  going to sell to anyone
 who used a web browser that supported SSL? It  was very simple
 economics, even if you had to pay VeriSign $400 for  your SSL
 certificate and pay Visa/MasterCard a higher fee.

can you say that that processing overhead was on the order of 20-30
seconds (on completely unloaded infrastrucutre ... demos at shows and
conferences ... can you imagine what a little bit of queuing load would
do to it?) ... if merchants thot SSL was onerous ... just imagine what
SET did to the infrastructure  and it provided effectively no
additional improvement over fraud vis-a-vis effectively only addressing
the confidentiality of account numbers as data-in-flight.

SSL was the encumbant, was significantly less complex and significantly
lighter weight (even tho most merchants decided that it was too heavy
except for the credit card portion) and provided effectively the same
amount of anti-fraud as SET.

If you had two products ... both effectively performing the same
function, one you already had deployed, which was significantly cheaper,
significantly simpler, and significantly faster, which one would you choose?

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


Re: the limits of crypto and authentication

2005-07-14 Thread Anne Lynn Wheeler
Pat Farrell wrote:
 As others have said, and in the spirit of the subject
 of this thread, SET failed for many reasons, many
 of them economic. There was little effort made
 to bribe the merchants, I think there was talk of
 a 26 basis point change in the discount rate,
 which the banks thought was huge and the merchants
 thought was noise. What really killed it
 was the billions it would have cost all
 the banks to issue and manage all the
 certificates.

this was some of the confusion between identification and
authentication. The SET effort was smart enuf to not do x.509 identity
certificates and instead do relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

and they even made comments about the enormous privacy and liability
issues raised with x.509 identity certificates.

They also avoided doing any sort of PKI infrastructure ... aka the
management and administration of the certificates. The effectively were
doing the same stuff as the original SSL domain name certificates ...
for which we coined the term certificate manufactoring (to
differentiate from a certificate administrative and management
operation). They basically said that the certificate only contained the
account number ... and the account number could be turned-off at the
issuing financial institution ... making it redundant and superfluous to
also have to have a separate infrastructure for invaliding the certifcate.

So they have an online infrastructure with real-time transactions and
real-time operation of the real information. It is an extremely trivial
additional step to show that then the certificates themselves are
redundant and superfluous.

The cost of the certificates only become an issue if you are talking
about having to pay a trusted third party, $100/annum for every certificate.

So we can take this in incremental steps.

1) you have the consumer's financial infrastructure register the public
key. they then can generate and issue a relying-party-only certificate
to the consumer (containing the consumer's public key and account number).

2) there was work started in X9 financial standards body on compressed
certificates. Even the SET relying-party-only certificate overhead ran
4k-12k bytes. The typical iso8583 financial message is on the order of
60-80 bytes. Even the trivial SET relying-party-only certificates
represented a payload bloat of one hundred times (besides the RSA-ops
inflating processing overhead by 3-4 orders of magnitude).

3) Because of the enormous payload bloat contributed by the
certificates, the digital signature processing was being truncated at
the internet boundary and a standard iso 8583 message was then generated
with a flag turned on indicating that the internet had validated the
digital signature. The merchants had an incentive to see that flag
turned on since that was the basis on which a lower discount was
calculated. At an ISO meeting in europe ... one of the association
network people presented statistics on the number of iso 8583 messages
that they found with the flag turned on and they could prove that no
digital signature technology could have been involved

4) I presented an argument that a valid compressing technology is to
eliminate all fields from the (certificate) contents that were known to
already be in possession of the relying party. Since it could be proved
that all fields in the SET relying-party-only certificate were already
on file with at the consumer's financial institutions ... it would be
possible to eliminate all fields from the relying-party-only
certificates. If they preferred, i would start describing the process of
appending zero byte digital certificates as an alternative to describing
certificateless digital signature operation
http://www.garlic.com/~lynn/subpubkey.html#certless

5) The consumer's financial institution could effectively use the
existing business processes for registering PINs as a mechanism for
registering public keys. That is not known to be an expensive business
process. A consumer's financial institution then could set up a website
where the consumer could later retrieve their (redundant and superfluous
relying-party-only) digital certifcate. There is some integrity
constraints here ... but since the purpose of a digital certificate is
to spray it all over the world ... there isn't a lot of confidentiality
constraints (i.e. it doesn't hurt a lot if other people pick up your
digital certificate). However, since both the public key and the digital
certificate would already be on file ... you could require people to
perform digital signature authentication before picking up their
redundant and superfluous digital certificate. This does have an
unfortunate downside since it highlights that consumer digital
signatures can be validated by onfile public keys w/o needing digital
certificates

6) there were lots of comments that leaving all the PKI gorp in the
hands of trusted third parties was a trade-off of the

Re: the limits of crypto and authentication

2005-07-13 Thread R.A. Hettinga
At 2:48 PM -0700 7/12/05, Bill Stewart wrote:
It'd be nice if good crypto and authentication methods
could create a market for improved products

It can, it does, and it's called significantly reduced risk-adjusted
transaction cost in financial econ-speak. Maybe the marketing droids need
to come up with a 50's-era secret ingredient, a cryptographic
Floristan(tm), but frankly, I don't think they're going to have to.

Frankly, however, I think that reduced transaction costs creates
*dis*economies of scale by reducing barriers to market entry and thus
firm-size, and reducing proprietary anything to fungible graded commodities
traded in so-called (see your Econ 51 textbook) perfectly competitive
markets, instead of monopolistic competition (brands, trademarks, patents
and other artifacts of batch-driven industrial production), which is what
we have today. Think of it as the financial equivalent of grey-goo, or,
better, blood-music, or whatever.

Linux vs Novel/MS-DOS/Unix(tm) for instance, or, again better, IETF-esque
protocols replacing various proprietary secret-sauce bit-slinging methods.

BTW, Perry, I think that as we get to online instantaneity for every
transaction, we eventually converge to pre-underwritten pre-encrypted
pre-authenticated quasi-anonymous unique value-bits circulating on public
networks: internet bearer financial cryptography protocols, in other words.

Cheers,
RAH
But you *knew* I was gonna say *that*, right?
-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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


Re: the limits of crypto and authentication

2005-07-12 Thread dan

Well, whether you like the cell phone as
the out-of-band second-factor, you can now
unlock your front door with it...

http://weblog.physorg.com/news2334.html

--dan


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


Re: the limits of crypto and authentication

2005-07-12 Thread Ben Laurie

Perry E. Metzger wrote:

Florian Weimer [EMAIL PROTECTED] writes:


* Perry E. Metzger:


Nick Owen [EMAIL PROTECTED] writes:


It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.


Far better would be to have a token with a display attached to the
PC. The token will display a requested transaction to the user and
only sign it if the user agrees. Because the token is a trusted piece
of hardware that the user cannot install software on, it provides a
trusted communications path to the user that the PC itself cannot.


On the surface, we already have such technology in Germany (it's
optional for bank customers), but there's a drawback: The external
device doesn't know anything about the structure of banking
transactions, so it relies on the (potentially compromised) host
system to send the correct message to display before generating the
signature.  Ouch.



That could be fixed. I think the right design for such a device has it
only respond to signed and encrypted requests from the issuing bank
directed at the specific device, and only make signed and encrypted
replies directed only at the specific issuing bank. If anything in
between can tamper with the communications channel you don't have the
properties you want out of this.


Not entirely clear what you mean by the issuing bank here, but I'm 
hoping you don't mean that the bank issues the device - that would be 
very tedious.


I also find directed only at the specific issuing bank unclear - I 
presume you mean encrypted s.t. only the issuing bank can read it? In 
which case, you're adding complexity - a relying party has to let the 
issuing bank come between it and you to get anywhere. This would 
preclude, for example, offline transactions.


As I've said before, I totally agree that the only way to go is to have 
signatures made on such a device, but I do think its very important to 
design the thing right - and the above isn't sounding right to me.


Cheers,

Ben.

--
ApacheCon Europe   http://www.apachecon.com/

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]


Re: the limits of crypto and authentication

2005-07-12 Thread Perry E. Metzger

Ben Laurie [EMAIL PROTECTED] writes:
 That could be fixed. I think the right design for such a device has
 it only respond to signed and encrypted requests from the issuing
 bank directed at the specific device, and only make signed and
 encrypted replies directed only at the specific issuing bank. If
 anything in between can tamper with the communications channel you
 don't have the properties you want out of this.

 Not entirely clear what you mean by the issuing bank here, but I'm
 hoping you don't mean that the bank issues the device - that would be
 very tedious.

Tedium is something that computers do very well. They don't care about
how much work they have to do. The only issue is whether we induce too
many serialized public key operations, and thus too much delay.

 I also find directed only at the specific issuing bank unclear - I
 presume you mean encrypted s.t. only the issuing bank can read it?

Yup. I want that for a variety of reasons.

 In which case, you're adding complexity - a relying party has to let
 the issuing bank come between it and you to get anywhere.

That's the case already. Only the issuing bank knows if the account
has any credit left in it, after all.

 This would preclude, for example, offline transactions.

We used to live in an era where offline transactions were
important. Now that you can get online literally anywhere, and now
that merchants pretty much are required to check card validity and
funds availability online anyway, that's no longer an interesting
concern. I can't think of the last time I was involved in an offline
transaction -- even folks at street fairs can now afford GPRS and
similar communications for their veriphone (and similar) units.

 As I've said before, I totally agree that the only way to go is to
 have signatures made on such a device, but I do think its very
 important to design the thing right - and the above isn't sounding
 right to me.

It sounds right to me, because it puts the trust relationships in all
the right places. The merchant trusts the accepting bank that it will
be paid. The accepting bank trusts the card network, the card network
trusts the issuing bank. The issuing bank and cardholder have a
bilateral relationship, too. If we keep the cryptographic exchanges
purely in correspondence with the trust relationships, and we get rid
of reliance on third party certification of public keys entirely, we
also fix most of the trouble in the system.

By the way, I note as an aside that this also means (in my opinion)
that certificates are no longer an interesting technology for
payments protocols, because in a purely online environment, you
never need a third party x.509 certificate in the course of the
payments protocol itself when there are no offline components of the
protocol and all relationships are bilateral.

The overwhelming disadvantage is deployment complexity, but given
deployment (ha, what an assumption on my part!) the system would work
very cleanly indeed.

The user would not have to worry about his PC being infected or his
merchant deploying a dishonest terminal (though theft of a token +
beating the PIN out of the user would still be an issue). By not
responding to requests that do not come from the issuing bank
specifically encrypted for the token, you reduce (though of course not
eliminate) the possibility of side channel attacks or inducing buffer
overflows and such in the token, as well as depriving intermediate
entities of privacy damaging information. The issuing bank would not
have worry about the origin of the token's signature -- it could be
reasonably assured that, short of physical attacks on the tokens
(which would happen but be infrequent), the signature came from the
token, and no information that would permit independent payment
authorizations has been left with the merchant or card processor.

Overall, I think such things are a win.


Perry

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


Re: the limits of crypto and authentication

2005-07-12 Thread Mads Rasmussen


In Brazil there's alot of trojans similar to the one Steven mentioned, 
almost all of them targeted at diferent national banks.


A while back they worked as external pop-ups as we named them. That is 
they appeared on top of the browser appearing visually like when you are 
asked for your credencials by the bank (although many times they ask for 
all your data including ssn).
Now a days they are more advanced, we have seen trojans lately that 
closes the browser and opens a window just like IE and then navigates 
the banks site inside, when it comes to entering the credencials it 
shows more fields to fill in than normal.

They often come with keyloggers too to rob your pin number as you enter it.
That made the banks use virtual keyboards, entering the PIN with the 
mouse on screen, to avoid entering PIN numbers via the keyboard.
Then the bad guys started using mouse loggers that captures a tiny 
square with every mouse click.


The captured data are sent via smtp, ftp or via an http post.

The latest trick is to encrypt the captured data with AES although the 
key is fixed in the code ;-)





Steven M. Bellovin wrote:

There's been a lot of discussion about how to strengthen cryptography 
and authentication, to get away from problems of phishing, pharming, 
etc.  But such approaches can take you only so far, as this link 
indicates:


http://www.lurhq.com/grams.html

Briefly, it's a Trojan that waits for you to log int o E-Gold, checks 
your balance, and drains your account except for .004 grams of gold.
 


--
Mads Rasmussen
Security Consultant
Open Communications Security
+55 11 3345 2525



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


Re: the limits of crypto and authentication

2005-07-12 Thread Ben Laurie

Perry E. Metzger wrote:

Ben Laurie [EMAIL PROTECTED] writes:


That could be fixed. I think the right design for such a device has
it only respond to signed and encrypted requests from the issuing
bank directed at the specific device, and only make signed and
encrypted replies directed only at the specific issuing bank. If
anything in between can tamper with the communications channel you
don't have the properties you want out of this.


Not entirely clear what you mean by the issuing bank here, but I'm
hoping you don't mean that the bank issues the device - that would be
very tedious.



Tedium is something that computers do very well. They don't care about
how much work they have to do. The only issue is whether we induce too
many serialized public key operations, and thus too much delay.


Sure, but multiple physical devices aren't my computer's problem, 
they're my problem.



I also find directed only at the specific issuing bank unclear - I
presume you mean encrypted s.t. only the issuing bank can read it?


Yup. I want that for a variety of reasons.



In which case, you're adding complexity - a relying party has to let
the issuing bank come between it and you to get anywhere.


That's the case already. Only the issuing bank knows if the account
has any credit left in it, after all.


This would preclude, for example, offline transactions.


We used to live in an era where offline transactions were
important. Now that you can get online literally anywhere, and now
that merchants pretty much are required to check card validity and
funds availability online anyway, that's no longer an interesting
concern. I can't think of the last time I was involved in an offline
transaction -- even folks at street fairs can now afford GPRS and
similar communications for their veriphone (and similar) units.


There are reasons to want to do offline transactions and to not have 
intermediaries that go beyond mere connectivity. Anonymity being the one 
of most concern to me, but I'll wager there are others.


Cheers,

Ben.

--
ApacheCon Europe   http://www.apachecon.com/

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]


Re: the limits of crypto and authentication

2005-07-12 Thread Anne Lynn Wheeler
Perry E. Metzger wrote:
 By the way, I note as an aside that this also means (in my opinion)
 that certificates are no longer an interesting technology for
 payments protocols, because in a purely online environment, you
 never need a third party x.509 certificate in the course of the
 payments protocol itself when there are no offline components of the
 protocol and all relationships are bilateral.

my impression of the 3party x.509 identity certificate model of the
early 90s ... was that every person would pay $100/annum for their
identity certificate grossly overloaded with personal information.

the certificate model has a design point from the early 80s, offline
email, where the receiver dials their local (electronic) postoffice,
exchanges email and hangs up. they then are faced with dealing with
first time email from total strangers. the x.509 identity certificates,
grossly overloaded with personal information ... were targeted at
(hopefully) including at least one piece of personal information (about
the sender), that the receiver might find useful when dealing with total
stranger.

moving into the early 90s, with a model where everybody would have
$100/annum identity certificates ... the apparent business model would
be that all established business relationships would be done away with
... and people would only be performing spontaneous business
transactions with total strangers ... supported by the x.509 identity
certificates. For instance, rather than depositing money in an
established bank account  you would spontaneously contact a total
stranger to accept your large sums of money. The exchange of x.509
identity certificates with total strangers would provide sufficient
trust and integrity to safegard your large sums of money.

Moving into the mid-90s, some institutions started to realize that such
x.509 identity certificates represented huge privacy and liability
issues and there was some implementations by financial institutions of
relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

which only contained a public key and some sort of database lookup index
 (as unique information) along with a lot of CPS and other types of
certification accounting gorp. In this situation, it was trivial to show
that such relying-party-only certificates were redundant and
superfluous: the relying party already has all the necessary information
on file, which invalidates the certificate design point of providing
letters of credit type of information between two strangers in first
time communicate (where there is no other recourse for information about
the party you are dealing with).

of course, there was a side issue in these payment protocols from the
period. the typical iso8583 payment message is on the order of 60-80
bytes. the typical overhead for even the relying-party-only certificates
(attached to every payment message) was on the order of 4k-12k bytes ...
leading to an enormous payload bloat of one hundred times for something
that was totally redundant and superfluous.

In general, the design point of x.509 identity certificates were to turn
all transactions (regardless of kind, even the most lightweight
authentication transactions) into heavyweight identification operations.

You would even find some govs. passing legislation that was oriented
towards mandating x.509 identity certificate be appended to every
digital signed transaction ... even when you might be looking at purely
a lightweight something you have authentication operation.


misc. recent posts on the subject:
http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big
problem with meaning
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand

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


Re: the limits of crypto and authentication

2005-07-12 Thread Anne Lynn Wheeler
Perry E. Metzger wrote:
 Ah, I see what you mean.
 
 Sadly, I don't think there is much to be done about that, but I think
 that (personally) I'd only end up with two of the things. If they can
 be made credit card sized, I don't see this as worse than what I have
 to carry now.

there are a couple of issues. in some ways  if institutional-centric
physical tokens were to be succesful ... you would start to see one in
lieu of ever pin, password, /or shared secret ... for every possible
type of relationship requiring authentication.

there was an issue in the early e-commerce days
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

a lot of the funding for the early commerce server work was targeted at
a mall type environment/experience ... where a large outsourcer would
provide electronic mall space for retail stores. The apparent
assumption was that the physical distance metaphor addressed by shopping
malls, would be carried over into the internet. however, the basic
characteristic of the internet  the world-wide-web already was
obliterated physical distance concepts. the issue then was why would a
metaphor designed to address physical distance limitations, carry over
into an environment where physical distance was a meaningless concept.

the issue with many of the existing issued cards and tokens are that
they are institutional-centric, one per institution. this could approach
the DRM/copy-protect approach of the mid-80s ... where applications were
being shipped with unique floppy disks that were required to be mounted
anytime the application was executed. an operation with one or two such
applications wouldn't be so bad ... but can you imagine that being
succesful today?  where you might have hundreds of such floppy disks
and requirement to have a dozen such floppy disks concurrently mounted
in a single floppy drive ... and possibly having to select and exchange
floopy disks (from a pile of hundreds) several times a minute.

i contend that the physical store checkout and payment model ... where
you are physically performing checkout and can likely do only one such
at a time  has analogies to the shopping mall physical metaphor
model ... and it starts to hit limitations when you translate that into
internet electronic metaphor with the possibility of multiple things
going on concurrently

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


Re: the limits of crypto and authentication

2005-07-12 Thread Perry E. Metzger

Ben Laurie [EMAIL PROTECTED] writes:
 Perry E. Metzger wrote:
 Anonymity is a concern to me, too, but I suspect that it is hard to
 get anonymity in a credit card transaction using current means, even
 if the merchant isn't online. Pseudonymity, perhaps.

 Can we not aim higher than merely doing as badly as current systems do?

I think that by eliminating the need for a merchant to learn
information about your identity I have aimed higher. Given that we're
talking about credit instruments, however, it may be difficult to
eliminate the need for the issuer to track transactions. However,
given the way I've described the protocol, it would be possible to use
a variant on it for digital cash purses without the merchant being
impacted. It isn't clear to me, though, who would issue such things in
the current environment.

Perry

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


Re: the limits of crypto and authentication

2005-07-12 Thread Bill Stewart

At 09:29 PM 7/9/2005, Perry E. Metzger wrote:

The Blue Card, so far as I can tell, was poorly thought out beyond its
marketing potential. I knew some folks at Amex involved in the
development of the system, and I did not get the impression they had
much of a coherent idea of what the technologies would be used for
other than creating marketing buzz.


On the other hand, only a short time before that,
Apple's iMac created a whole marketing revolution
and set of spinoff products and revitalized the company
by coming out with a semi-transparent blue-green case
that effectively packaged the Reality Distortion Field,
and they were able to maintain the effect over several years
by the radical introduction of several other semi-transparent colors.

It'd be nice if good crypto and authentication methods
could create a market for improved products,
but hey, if blue-green translucent dancing pigs gets customers,
the marketing people have done _their_ job.




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


Re: the limits of crypto and authentication

2005-07-12 Thread Adam Shostack
On Tue, Jul 12, 2005 at 02:48:02PM -0700, Bill Stewart wrote:
| At 09:29 PM 7/9/2005, Perry E. Metzger wrote:
| The Blue Card, so far as I can tell, was poorly thought out beyond its
| marketing potential. I knew some folks at Amex involved in the
| development of the system, and I did not get the impression they had
| much of a coherent idea of what the technologies would be used for
| other than creating marketing buzz.
| 
| On the other hand, only a short time before that,
| Apple's iMac created a whole marketing revolution
| and set of spinoff products and revitalized the company
| by coming out with a semi-transparent blue-green case
| that effectively packaged the Reality Distortion Field,
| and they were able to maintain the effect over several years
| by the radical introduction of several other semi-transparent colors.
| 
| It'd be nice if good crypto and authentication methods
| could create a market for improved products,
| but hey, if blue-green translucent dancing pigs gets customers,
| the marketing people have done _their_ job.

In light of the ID theft drumbeat, companies that don't require your
SSN have a marketable edge.  I'm waiting for some to use it.

Adam

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


RE: the limits of crypto and authentication

2005-07-11 Thread Scott Guthery
Amex Blue was a market success in the sense that its ROI exceeded
expectations, rational and otherwise.  It yielded thousands of new
accounts at a cost of acquisition far less than average, even when
taking into account the Windows driver support calls and the discarded
readers. That said, you might have been able to achieve the same result
with a gold stickie except the geeks that were the majority of the new
accounts probably would have peeled it off and grumped.

The winner will be the dude that can make authentication into a Mustang.
Like it or not, Amex Blue pointed the way.

IMHO as always.

Cheers, Scott

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Saturday, July 09, 2005 6:32 PM
To: cryptography@metzdowd.com
Subject: Re: the limits of crypto and authentication 


Nick Owen writes:
 | I think that the cost of two-factor authentication will plummet in
the  | face of the volumes offered by e-banking.

Would you or anyone here care to analyze what I am presuming is the
market failure of Amex Blue in the sense of its chipcard and reader
combo?

--dan


-
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: the limits of crypto and authentication

2005-07-11 Thread Nick Owen
I think the failure of Amex Blue is due to poor timing and the
requirement for hardware on the end-user's PC.  At the time of it's
introduction ecommerce and online banking were just getting started and
consumers were more worried about whether the store was real or not than
having their card stolen.  It wasn't until identity theft and the rush
of disclosures due to SB1386 et al here in the US that people cared
about security and privacy (in some way).

What I can't understand is why Visa and Amex haven't started to push
their one-time credit card software solutions again - this time as
protection for your privacy.  I would think people would be much more
receptive to it now.  Little has changed, except the market's perception
of the risk of using credit cards online. Amex actually pulled their
program in 2004, IIRC.

[EMAIL PROTECTED] wrote:
 Nick Owen writes:
  | I think that the cost of two-factor authentication will plummet in the
  | face of the volumes offered by e-banking.
 
 Would you or anyone here care to analyze
 what I am presuming is the market failure
 of Amex Blue in the sense of its chipcard
 and reader combo?
 
 --dan
 
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
 

-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor

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


Re: the limits of crypto and authentication

2005-07-11 Thread Anne Lynn Wheeler
Perry E. Metzger wrote:
 Far better would be to have a token with a display attached to the
 PC. The token will display a requested transaction to the user and
 only sign it if the user agrees. Because the token is a trusted piece
 of hardware that the user cannot install software on, it provides a
 trusted communications path to the user that the PC itself cannot.

this is also the EU finread standard
http://www.garlic.com/~lynn/subpubkey.html#finread

which has a certified display and certified pin-pad. it was for token
reader external to the PC ... so that what is displayed is what gets
signed ... and the PIN entry isn't easily compromised. This still
somewhat assumed standard 7816 card w/o its own display and pin-entry.

the issue in x9.59 design
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#privacy

was that it was possible for the relying party to get certified
integrity information about the hardware token at the time the public
key was registered  and recheck that certified integrity information
(binding to the public key) on every digitally signed transaction ...
the EU finread standard didn't provide for the similar level of assurance.

x9.59 allowed (but didn't mandate) that the environment, in which the
signing took place, could also digitally sign the transaction. this
could provide the relying party a binding not only between the integrity
of the token doing the digital signing  but also a binding between
the environment that the digital signing took place and the integrity of
that binding.

The base EU finread terminal scenario provides for a standard for high
integrity digital signing environment. However, it doesn't provide for
any proof to the relying party that such a terminal was actually used
for any specific transaction. Having the public key of the EU finread
terminal registered along with the associated certified integrity level
of that environment  then if such a terminal was also to digitally
sign the transaction, the relying party could do some risk assesement
both on the integrity of the token performing the digital signing (for
authentication purposes) and the integrity of the signing environment
(terminal).

If the display, pin-entry, and authentication token were tightly bound
in the same device  then when the relying party registered the
public key for authentication purposes  they would also register the
associated integrity characteristics of the hardware token (for
authentication purposes) as well as the display and pin-entry (for
integrity related to the signing environment).

The issue here is that the relying party is fundamentally interested in
the overall risk of the transaction ... which is composed of a lot of
individual integrity characteristics.

Relating this to the old style x.509 identity certificate  grossly
overloaded with personal information  a relying party ... can have
done an authentication binding regarding the public key (i.e. don't
necessarily need to have the identity of the person  such know that
the authentication indicates the entity is the one that is authorized to
performed the related operations  w/o having across the line from
auhentication into identification and grossly confusing the difference
between the two).

One the relying party has done the straigth-forward authentication
binding for a hardware token and a public key  the really
interesting charactistics for the relying party is all the integrity
characteristics surrounding a transactions.

To some estent, the PKI identity-centric focus have tended to distract
relying parties from the more fundamental risk issues regarding
integrity characteristics of performing the transaction. One an entity
is registered as enabled for performing valid transactions (which can be
a purely authentication operation w/o getting grossly confused about the
difference between authentication and identification), then issues of
certification interest to a relying party are the integrity
characteristics of the authentication events (and the enormous
concentration by PKI bodies on confusing identification with
authentication tends to be a pure distraction to the risk assesement of
the operations).

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


Re: the limits of crypto and authentication

2005-07-11 Thread Amir Herzberg

Steven M. Bellovin wrote:
There's been a lot of discussion about how to strengthen cryptography 
and authentication, to get away from problems of phishing, pharming, 
etc.  But such approaches can take you only so far, as this link 
indicates:


http://www.lurhq.com/grams.html

Briefly, it's a Trojan that waits for you to log int o E-Gold, checks 
your balance, and drains your account except for .004 grams of gold.


Steve, thanks. Not really much of surprise, is it? Clearly, a user who 
lets malware onto his/her PC, e.g. a VBscript in this case, has lost 
control and is open to such attacks.


But... crypto and authentication, imho, are the best tools to prevent 
such malware from being installed. Yes, I know, this is far from the 
current situation, with corrupted PCs (Zombies) being a very large 
fraction (around a third?)...

--
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI: 
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages: 
http://AmirHerzberg.com/shame


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


Re: the limits of crypto and authentication

2005-07-11 Thread Nick Owen
I think the difference now is the number of vendors entering the market,
 the variety of solutions ( and their relative security), and demand
outside of Europe.  When we started in mid-2001, we were looking at the
existing hardware guys and that is it.  Now there a handful of
venture-backed software players with different solutions all targeting
the banking market, which didn't exist then.

We have not seen any interest in our two-factor solution from Germany or
any country where they have some form of two-factor authentication.
Perhaps this is similar to the US corporate market where companies that
have tokens aren't very interested in switching to save money - the CSO
only takes risk in switching and sees no personal benefit in reducing
costs (my theory at least) so there's no true vetting, only beating up
the current vendor for a slightly better deal. Thus your banks will
still complain that the price of mailing paper is too high, which of
course it is when compared to software tokens.

We are, however, seeing interest from US and South American banks and
the numbers are huge and we will be very aggressive in pricing.  We also
see that we are competing against companies that use IP address
verification, secure cookies and other things that are readily
compromised, but apparently easy to roll-out and maintain and
inexpensive.  So, we have to compete against those substitutes that
don't even use cryptography or two-factor authentication but would be
better termed as fraud detection and prevention.



Florian Weimer wrote:
 * Nick Owen:
 
 
I think that the cost of two-factor authentication will plummet in the
face of the volumes offered by e-banking.
 
 
 I doubt this is true.  In Germany, we already use some form of
 two-factor authentication for Internet banking transaction (account
 number/password and a one-time password for each transaction).  Yet
 banks are desperately looking for alternatives because distributing
 those one-time password lists is too expensive (!).  To me, this was
 quite surprising because it's just one sheet of paper every 200
 transactions or so.
 
 Even worse, this scheme has failed, and there are successful attacks
 in the wild (involving compromised client PCs).  Right now,
 time-dependent tokens do help, but only because you outrun the other
 guy.  The real-time requirements imposed by them are not a fundamental
 obstacle to the attackers, and even now, the way they route the money
 makes it very hard to detect things in real-time (at least on the
 money side).
 
 Well, you can imagine my surprise when Howard Schmidt praised
 two-factor authentication as a solution to our current problems at the
 FIRST 2005 conference. 8-/
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
 

-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor

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


Re: the limits of crypto and authentication

2005-07-11 Thread Florian Weimer
* Perry E. Metzger:

 Nick Owen [EMAIL PROTECTED] writes:
 It would seem simple to thwart such a trojan with strong authentication
 simply by requiring a second one-time passcode to validate the
 transaction itself in addition to the session.

 Far better would be to have a token with a display attached to the
 PC. The token will display a requested transaction to the user and
 only sign it if the user agrees. Because the token is a trusted piece
 of hardware that the user cannot install software on, it provides a
 trusted communications path to the user that the PC itself cannot.

On the surface, we already have such technology in Germany (it's
optional for bank customers), but there's a drawback: The external
device doesn't know anything about the structure of banking
transactions, so it relies on the (potentially compromised) host
system to send the correct message to display before generating the
signature.  Ouch.

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


Re: the limits of crypto and authentication

2005-07-11 Thread Florian Weimer
 Take a look at Boojum Mobile -- it is
 precisely the idea of using the cell
 phone as an out-of-band chanel for an
 in-band transaction.

 http://www.boojummobile.com

In the foreseeable future, this approach won't stop fraudulent
transactions because the one-time password does not depend on the
transaction content.  Anything which doesn't display essential parts
of the transaction contents to the end user over a trusted channel is
doomed to failure.

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


Re: [Anti-fraud] Re: the limits of crypto and authentication

2005-07-11 Thread Ka-Ping Yee
On Sun, 10 Jul 2005, Amir Herzberg wrote:
 But... crypto and authentication, imho, are the best tools to prevent
 such malware from being installed.

I disagree.  Limited authority is the best way to prevent such malware
from being installed (and, if installed, from causing harm).

The premise that all software can be divided into categories of good
and evil is a deeply flawed foundation on which to build security.


-- ?!ng

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


Re: the limits of crypto and authentication

2005-07-11 Thread Peter Gutmann
[EMAIL PROTECTED] writes:

Take a look at Boojum Mobile -- it is precisely the idea of using the cell
phone as an out-of-band chanel for an in-band transaction.

http://www.boojummobile.com

Banks here have been using it to authenticate higher-value electronic
transactions as well.  The way it works is that for transactions with a
combined value over the default floor limit of NZ$2.5K you have to use an
additional PIN sent via SMS to a pre-configured number to authenticate the
session.  The PIN authenticates that particular session (not just one
transaction), with a fee of NZ$0.25.  It's not perfect, obviously, but that
was seen as the best tradeoff between cost, user convenience, and security.

grumbleA few years ago I wanted to do this out-of-band authentication as a
research project, and at the time couldn't find anyone interested in it; now
they've paid an arm and a leg for it themselves, sigh/grumble.

Peter.

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


Re: the limits of crypto and authentication

2005-07-11 Thread Anne Lynn Wheeler
Nick Owen wrote:
 I think that the cost of two-factor authentication will plummet in the
 face of the volumes offered by e-banking.  Also, the more uses for the
 token, the more shared the costs will be.  The question to me is will
 the FIs go with a anything beyond secure cookies, IP address validation
 and unique images.  Will they be forced to by the powers that be or by
 disclosure requirements after the basic systems are thwarted?

two-factor authentication per se, isn't necessarily the panecea.

pin-debit ... has a magstripe card as something you have and a pin as
something you know. as recently mentioned, compromised ATM /or POS
machines have been able to skim the magstripe and the pin  enabling
creation of counterfeit cards and fraudulent transaction.

in x9.59,
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#privacy

a hardware token can digitally sign the actual financial transaction.
this would be single factor, something you have authentication.
skimming and/or harvesting the transaction and/or transaction log files
http://www.garlic.com/~lynn/subpubkey.html#harvest

doesn't enable either counterfeit cards and/or fraudulent transactions.

the issue of a PIN, in conjunction with the magstripe card for
two-factor authentication, was a countermeasure against lost/stolen
card. However, skimming as a threat, is able to capture both the PIN and
the card magstripe information, enabling fraudulent transactions.

a single-factor authentication hardware token (something you have)
that digitally signs the transaction is sufficient countermeasure
against skimming and harvesting.

Enforced PIN-debit ... i.e. where the magstripe can't be used w/o the
PIN ... turns out to be a countermeasure against some of the transaction
log harvesting (the type of data breach stories recently in the press)
... since the PIN information isn't normally carried in the transaction
log. The issue with the transaction log is that there are several other
merchant business processes that require access to transaction information.

The issue with magstripe and PINs ... is the threat and vulnerability
model effectively is a replay attack ... static data that can be
relatively easily recorded and repeated in fraudulent transactions
(and/or used to create counterfeit magstripe).

A single factor authentication hardware token that digitally signs
that transactions, is countermeasure against attacks recording static
data for replay-type attacks.

Adding a PIN or biometric authentication to a hardware token for two
factor authentication  doesn't improve the countermeasure to
skimming and harvesting attacks. The PIN or biometric authentication in
conjunction with a hardware token is primarily countermeasure for
lost/stolen token ... not countermeasure for skimming/harvesting
replayable information.

There is has been a separate issue with the use of pin/passwords
shared-secrets
http://www.garlic.com/~lynn/subpubkey.html#secrets

for something you know authentication, is people having large number
of different accounts  each, supposedly requiring unique something
you know shared secrets. The estimate is that possibly 30percent of the
debit cards have PINs written on them. The issue is basic human factors
and blindly adding something you know shared secret as a second
authentication factor doesn't necessarily significantly improve the
situation. so you are possibly faced with having to fundamentally rework
some of the authentication landscape to compensate for well documented
human short comings.

So two possible pieces for reworking this portion of the authentication
landscape (for human factor shortcomings with proliferation of large
number of shared-secrets)

1) certified tokens that accept PINs for operation. the PINs are
shared-secrets since they don't travel past the token. The token is in
the person's possession and the PIN is just for activating certified
token operation. this can contribute to the person being able to
initialize all tokens to the same PIN

2) transition from institution-centric tokens to person-centric tokens
... aka rather than every institution in the world issuing a token ...
and each token possibly requiring a single PIN, people can acquire some
small number of personal tokens and register their personal tokens for
valid something you have authentication at different institutions.


A big issue in the recent data breach stories with respect to security
PAIN acronym

P ... privacy
A ... authentication
I ... integirty
N ... non-repudiation

is that many of the infrastructures tend to have relatively strong
integrity requirements for their business records. this protects the
infrastructure business operations. however, they tend to have much
lower privacy requirements ... in part because the large number of
business processes that require access to those records. furthermore,
the privacy threats and vulnerabilities isn't directly against the
infrastructures  

Re: the limits of crypto and authentication

2005-07-11 Thread Ian Grigg
On Saturday 09 July 2005 23:31, [EMAIL PROTECTED] wrote:
 
 Nick Owen writes:
  | I think that the cost of two-factor authentication will plummet in the
  | face of the volumes offered by e-banking.
 
 Would you or anyone here care to analyze
 what I am presuming is the market failure
 of Amex Blue in the sense of its chipcard
 and reader combo?

There was no market failure - Amex Blue was
an outstanding success that sent waves of
astonishment through the credit card industry.
Everyone was talking about how stunningly
successful it was - how it had broken the laws
of account creation by actually acquiring new
accounts in the millions instead of cannibalising
existing accounts.  (I recall a number of 4 million?)

You may be thinking that the usage of the smart
card being a total and complete flop was in some
way correlated with the market success, but it
was quite the reverse - the smart card usage was
a complete and utter failure for the obvious reasons,
but the program itself was fantastically successful.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

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


Re: the limits of crypto and authentication

2005-07-11 Thread Perry E. Metzger

[EMAIL PROTECTED] writes:
 Nick Owen writes:
  | I think that the cost of two-factor authentication will plummet in the
  | face of the volumes offered by e-banking.

 Would you or anyone here care to analyze
 what I am presuming is the market failure
 of Amex Blue in the sense of its chipcard
 and reader combo?

The Blue Card, so far as I can tell, was poorly thought out beyond its
marketing potential. I knew some folks at Amex involved in the
development of the system, and I did not get the impression they had
much of a coherent idea of what the technologies would be used for
other than creating marketing buzz.

Perry

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


Re: the limits of crypto and authentication

2005-07-11 Thread Perry E. Metzger

Florian Weimer [EMAIL PROTECTED] writes:
 * Perry E. Metzger:
 Nick Owen [EMAIL PROTECTED] writes:
 It would seem simple to thwart such a trojan with strong authentication
 simply by requiring a second one-time passcode to validate the
 transaction itself in addition to the session.

 Far better would be to have a token with a display attached to the
 PC. The token will display a requested transaction to the user and
 only sign it if the user agrees. Because the token is a trusted piece
 of hardware that the user cannot install software on, it provides a
 trusted communications path to the user that the PC itself cannot.

 On the surface, we already have such technology in Germany (it's
 optional for bank customers), but there's a drawback: The external
 device doesn't know anything about the structure of banking
 transactions, so it relies on the (potentially compromised) host
 system to send the correct message to display before generating the
 signature.  Ouch.

That could be fixed. I think the right design for such a device has it
only respond to signed and encrypted requests from the issuing bank
directed at the specific device, and only make signed and encrypted
replies directed only at the specific issuing bank. If anything in
between can tamper with the communications channel you don't have the
properties you want out of this.

Given such a structure, however, you can know when the device displays
Pay 53.22 euros to amazon.fr for book X that this is precisely the
transaction you are authorizing, and that the communication will
not authorize any other transaction, its interception will not permit
the authorization of any other transaction, and no replay of the
transaction is possible.

However, you need both the end to end communication and the hardware
token with built in display and keyboard.

Perry

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


Re: the limits of crypto and authentication

2005-07-11 Thread Anne Lynn Wheeler
another characteristic of the PKI x.509 identity certificate activity
(besides attempting to create mass world-wide confusion regarding the
difference between identification and authentication ... and trying to
get govs. to mandate that x.509 identity certificates, grossly
overloaded with personal information had to be appended to even the most
simple of authentication transactions)  was trying to cause a great
deal of confusion about the difference between *digital signatures* and
*human signatures*. some of this possibly was semantic confusion because
both of the terms; *digital signature* and *human signature* contain the
word *signature*.

nominally a digital signature is the use of a private key to encode a
message/document hash. the relying party then recalculates the
message/document hash, uses the corresponding public key to decode the
digital signature, and compares the two hash. if they are equal, the
relying party assumes:

1) the message/document hasn't been altered (since the digital signature)

2) something you have authentication, aka the originator has access
and use of the private key.

the base technology is asymmetric key cryptography (what one key
encodes, the other key decodes). the business process of public key,
identifies one key as publicly available. the other key is kept
confidential and never divulged. the integrity of something you have
authentication can be improved by deploying secure hardware tokens where
the key pair are generated in the token and the private key never leaves
the token (improving the probability that the private key is never
divulged).

now, normal *human signature* implies read, understood, agrees,
approves, and/or authorizes. The normal *digital signature* is purely a
something you have authentication process implying none of the
characteristics of a *human signature*. In fact, a series of my pasts
posts on *dual-use attacks* was specifically with using the same private
key to apply digital signatures to random data (as part of
authentication operations) and digital signatures to non-random data
(assuming human signature characteristics).

Somewhat in support of helping create world wide confusion about the
differences between *digital signatures* and *human signatures* (in
addition to creating world wide confusion about the difference between
authentication and identification), the PKI x.509 digital certificate
standard also defined a non-repudiation bit. For some number of
PKI-oriented payment protocols in the mid-90s, there was the
specification of digital certificates with the non-repudiation bit
turned on. Supposedly, if a merchant could demonstrated any valid
digital certificate with the non-repudiation bit turned on (for the
customer's public key), then the burden of proof in any dispute would
have shifted from the merchant to the consumer. The threat/vulnerability
was

1) the PKI-oriented protocols provided no mechanism for proving which
certificate had been originally attached to the transaction

2) supposedly the non-repudiation bit was capable of turning any
digital signature operation (regardless of the environemnt in which the
signature had been performed) magically into a *human signature*
carrying the attributes of read, understood, agree, approve, and/or
authorized.

So the PKI x.509 identity digital certificates were targeted at

1) turning every transaction in the world (even the most trivial
authentication operation) into a heavy duty identification operation
(with attached x.509 identity digital certificates carrying enormous
amounts of personal information)

2) allowing anybody that could produce a valid digital certificate (for
the associated public key) with the non-repudation bit on, to magically
turn all associated *digital signatures* into *human signatures* (even
digital signatures that had been presumably been performed on random
data for purely authentication operations).

since that time, the use of the certificate-based non-repudiation bit
has been severely depreciated (many people coming to realize that it
takes more than magical PKI bits to turn *digital signatures* into
*human signatures*).

there were some that started to realize that the PKI x.509 identity
certificate model represented severe privacy and liability issues. The
initial quickdirty fix were the relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

containing just public key and some sort of database lookup index.

The issue here is that it is trivial to demonstrate that such
relying-party-only certificates are redundant and superfluous  if
the relying party already has all the information, then the relying
party can directly look up the necessary information (including
registered public key as well as all integrity characteristics that
might be associated with that public key ... and the last thing they
need are redundant and superfluous relying-party-only digital certificates).


Re: the limits of crypto and authentication

2005-07-11 Thread Ben Laurie

Peter Gutmann wrote:

[EMAIL PROTECTED] writes:



Take a look at Boojum Mobile -- it is precisely the idea of using the cell
phone as an out-of-band chanel for an in-band transaction.

http://www.boojummobile.com



Banks here have been using it to authenticate higher-value electronic
transactions as well.  The way it works is that for transactions with a
combined value over the default floor limit of NZ$2.5K you have to use an
additional PIN sent via SMS to a pre-configured number to authenticate the
session.  The PIN authenticates that particular session (not just one
transaction), with a fee of NZ$0.25.  It's not perfect, obviously, but that
was seen as the best tradeoff between cost, user convenience, and security.

grumbleA few years ago I wanted to do this out-of-band authentication as a
research project, and at the time couldn't find anyone interested in it; now
they've paid an arm and a leg for it themselves, sigh/grumble.


Back when we used to run O2's (then Cellnet) web stuff, we used to 
authenticate user accounts by sending random words to their phone. This 
was so long ago I can't remember when it was, but certainly  5 years.


Cheers,

Ben.

--
ApacheCon Europe   http://www.apachecon.com/

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]


Re: the limits of crypto and authentication

2005-07-11 Thread Anne Lynn Wheeler
Perry E. Metzger wrote:
 However, you need both the end to end communication and the hardware
 token with built in display and keyboard.

there is two issues for digital signatures ...

1) something you have authentication and

2) proof to the relying party as to the integrity level of the operations

it is possible to establish the integrity level of the hardware token at
the time the public key is registered ... and then possibly track the
token integrity level as it degrades over time (because of technology
advances).

in the EU finread standard case
http://www.garlic.com/~lynn/subpubkey.html#finread

it assumed that the display/pinpad and the token were separate. the the
case of relying party being able to evaluate the risk of the transaction
... then it would actually need the separate display/pinpad to also
digitally sign the transaction (and also having previously registered
the finread terminal public key and integrity level).

the co-signing by the separate display/pinpad was allowed for in x9.59
financial transaction standard
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/supubkey.html#privacy

but not mandated.

when the display, pinpad, and token are all a single device ... then
there would only be a requirement for a single digital signature ...
representing both the something you have authentication as well as the
integrity level of the signing environment.

in the *human signature* realm there is the aspect of many financial
point-of-sale termainals where there is requirement for some sort of
manual, human interaction that demonstrates some sort of agreement,
approval, and/or authorization of the transaction (in addition to the
authentication operation). frequently this is a display of the
transaction requiring the person to hit the agree/yes button ... as a
separate operation from any authentication operations.

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


the limits of crypto and authentication

2005-07-09 Thread Steven M. Bellovin
There's been a lot of discussion about how to strengthen cryptography 
and authentication, to get away from problems of phishing, pharming, 
etc.  But such approaches can take you only so far, as this link 
indicates:

http://www.lurhq.com/grams.html

Briefly, it's a Trojan that waits for you to log int o E-Gold, checks 
your balance, and drains your account except for .004 grams of gold.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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


Re: the limits of crypto and authentication

2005-07-09 Thread Nick Owen
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.

Steven M. Bellovin wrote:
 There's been a lot of discussion about how to strengthen cryptography 
 and authentication, to get away from problems of phishing, pharming, 
 etc.  But such approaches can take you only so far, as this link 
 indicates:
 
 http://www.lurhq.com/grams.html
 
 Briefly, it's a Trojan that waits for you to log int o E-Gold, checks 
 your balance, and drains your account except for .004 grams of gold.
 
   --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
 
 
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
 

-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor

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


Re: the limits of crypto and authentication

2005-07-09 Thread Steven M. Bellovin
In message [EMAIL PROTECTED], Nick Owen writes:
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.


How does the user know which transaction is really being authenticated?
(I alluded to this in a 1997 panel session talk; see
http://www.cs.columbia.edu/~smb/talks/ncsc-97/index.htm )

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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


Re: the limits of crypto and authentication

2005-07-09 Thread Nick Owen
To validate the transaction, a receipt could be sent to the user
encrypted by the server's public key.  If the receipt is correct, the
user enters their PIN to 'sign' the transaction.

I'm assuming an asymmetric authentication system here outside the
browser. The attacker would have to steal the user's private key, their
PIN and the server's private key, correct?

I know that if the PC is compromised anything is possible, but I think
this raises the bar significantly - perhaps to an unprofitably level.

Steven M. Bellovin wrote:
 In message [EMAIL PROTECTED], Nick Owen writes:
 
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.

 
 
 How does the user know which transaction is really being authenticated?
 (I alluded to this in a 1997 panel session talk; see
 http://www.cs.columbia.edu/~smb/talks/ncsc-97/index.htm )
 
   --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
 
 
 

-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor

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


Re: the limits of crypto and authentication

2005-07-09 Thread Lance James

Steven M. Bellovin wrote:

There's been a lot of discussion about how to strengthen cryptography 
and authentication, to get away from problems of phishing, pharming, 
etc.  But such approaches can take you only so far, as this link 
indicates:


http://www.lurhq.com/grams.html

Briefly, it's a Trojan that waits for you to log int o E-Gold, checks 
your balance, and drains your account except for .004 grams of gold.
 




There is a possible solution against an OLE event driven session rider 
such as this one. The solution I proposed was to use a variant of 
CAPTCHA that would add mutual authentication in the mix within the 
picture. Yes, there are some people that say CAPTCHA can be broken, but 
in the game of phishing, it's abouit numbers, not about silver bullets. 
The way to get around the porn CAPTCHA problem was to ask something 
that the user might only know and then ask the user about the activity 
they are performing.


This would stop this instance of E-gold attacks.


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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


 




--
Best Regards,
Lance James
Secure Science Corporation
www.securescience.net
Author of 'Phishing Exposed'
http://www.securescience.net/amazon/
Find out how malware is affecting your company: Get a DIA account today!
https://slam.securescience.com/signup.cgi - it's free!


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


Re: the limits of crypto and authentication

2005-07-09 Thread Florian Weimer
* Steven M. Bellovin:

 In message [EMAIL PROTECTED], Nick Owen writes:
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.


 How does the user know which transaction is really being authenticated?

You send the pass code in an SMS to the user's mobile phone, together
with some information on the transaction.  (If the SMS delay is a
problem, use a computer-generated phone call.)  The pass code is then
entered by the user to authorize the transaction.

This will eventually break down, once PCs and mobile phones are
integrated tightly, but in the meantime, it's reasonably secure even
if the client PC is compromised.

I'm not sure if users will accept it, though.  What's worse, the costs
for sending the SMS message (or making the phone call) are so
significant that it's unrealistic we'll see widespread use of such
technologies.

(Manually transferring cryptographic tokens which depend on the
transaction contents seems to be infeasible, given the number of bits
which must be copied.)

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


Re: the limits of crypto and authentication

2005-07-09 Thread Ian Grigg
FTR, e-gold were aware of the general makeup of this
threat since 1998 and asked someone to look at it.  The
long and the short was that it was more difficult to solve
than at first claimed, so the project was scrapped.  This
was a good risk-based decision.  The first trojans that I
know of for e-gold weren't spotted until 12-18 months
ago, so it was also a profitable decision.  What they are
doing now I don't know.

In the payments world we've known how to solve all
this for some time, since the early 90s to my knowledge.
The only question really is, have you got a business
model that will pay for it, because any form of token is
very expensive, and the form of token that is needed -
a trusted device to put the application, display, keypad
and net connection on - is even more expensive than
the stop-gap two-factor authentication units commonly
sold.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

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


Re: the limits of crypto and authentication

2005-07-09 Thread Nick Owen
I think that the cost of two-factor authentication will plummet in the
face of the volumes offered by e-banking.  Also, the more uses for the
token, the more shared the costs will be.  The question to me is will
the FIs go with a anything beyond secure cookies, IP address validation
and unique images.  Will they be forced to by the powers that be or by
disclosure requirements after the basic systems are thwarted?

I also think that the lower end cell phone is now capable of handling
the task.  While a PC client may not be very secure, it does offer some
potential benefits such as auto-validating SSL certs.  Whether the
carriers will bother with a potential revenue stream in two-factor
authentication when they can make more money in ringtones is another
question - back to the business model ;).

Ian Grigg wrote:
 FTR, e-gold were aware of the general makeup of this
 threat since 1998 and asked someone to look at it.  The
 long and the short was that it was more difficult to solve
 than at first claimed, so the project was scrapped.  This
 was a good risk-based decision.  The first trojans that I
 know of for e-gold weren't spotted until 12-18 months
 ago, so it was also a profitable decision.  What they are
 doing now I don't know.
 
 In the payments world we've known how to solve all
 this for some time, since the early 90s to my knowledge.
 The only question really is, have you got a business
 model that will pay for it, because any form of token is
 very expensive, and the form of token that is needed -
 a trusted device to put the application, display, keypad
 and net connection on - is even more expensive than
 the stop-gap two-factor authentication units commonly
 sold.
 
 iang

-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor

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


Re: the limits of crypto and authentication

2005-07-09 Thread Perry E. Metzger

Nick Owen [EMAIL PROTECTED] writes:
 It would seem simple to thwart such a trojan with strong authentication
 simply by requiring a second one-time passcode to validate the
 transaction itself in addition to the session.

Far better would be to have a token with a display attached to the
PC. The token will display a requested transaction to the user and
only sign it if the user agrees. Because the token is a trusted piece
of hardware that the user cannot install software on, it provides a
trusted communications path to the user that the PC itself cannot.

Perry

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


Re: the limits of crypto and authentication

2005-07-09 Thread dan

Florian Weimer writes:
 | 
 | It would seem simple to thwart such a trojan with strong authentication
 | simply by requiring a second one-time passcode to validate the
 | transaction itself in addition to the session.
 | 
 | 
 |  How does the user know which transaction is really being authenticated?
 | 
 | You send the pass code in an SMS to the user's mobile phone, together
 | with some information on the transaction.  (If the SMS delay is a
 | problem, use a computer-generated phone call.)  The pass code is then
 | entered by the user to authorize the transaction.


[ Disclaimer -- I advise this company ]

Take a look at Boojum Mobile -- it is
precisely the idea of using the cell
phone as an out-of-band chanel for an
in-band transaction.

http://www.boojummobile.com

[ Disclaimer -- I advise this company ]

--dan




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


Re: the limits of crypto and authentication

2005-07-09 Thread dan

Nick Owen writes:
 | I think that the cost of two-factor authentication will plummet in the
 | face of the volumes offered by e-banking.

Would you or anyone here care to analyze
what I am presuming is the market failure
of Amex Blue in the sense of its chipcard
and reader combo?

--dan


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


Re: the limits of crypto and authentication

2005-07-09 Thread Florian Weimer
* Nick Owen:

 I think that the cost of two-factor authentication will plummet in the
 face of the volumes offered by e-banking.

I doubt this is true.  In Germany, we already use some form of
two-factor authentication for Internet banking transaction (account
number/password and a one-time password for each transaction).  Yet
banks are desperately looking for alternatives because distributing
those one-time password lists is too expensive (!).  To me, this was
quite surprising because it's just one sheet of paper every 200
transactions or so.

Even worse, this scheme has failed, and there are successful attacks
in the wild (involving compromised client PCs).  Right now,
time-dependent tokens do help, but only because you outrun the other
guy.  The real-time requirements imposed by them are not a fundamental
obstacle to the attackers, and even now, the way they route the money
makes it very hard to detect things in real-time (at least on the
money side).

Well, you can imagine my surprise when Howard Schmidt praised
two-factor authentication as a solution to our current problems at the
FIRST 2005 conference. 8-/

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


Re: the limits of crypto and authentication

2005-07-09 Thread James A. Donald
--
Ian Grigg [EMAIL PROTECTED]
 In the payments world we've known how to solve all 
 this for some time, since the early 90s to my
 knowledge. The only question really is, have you got a
 business model that will pay for it, because any form
 of token is very expensive, and the form of token that
 is needed - a trusted device to put the application,
 display, keypad and net connection on - is even more
 expensive than the stop-gap two-factor authentication
 units commonly sold.

Such a device sounds like a cell phone.


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 5nMEZ3YWGEUKZWzEprv/E7vI+8j9jzBNX8GWiJiO
 4nb4BSDrVGLfq42fHktPRSAfFO3N0uGBnezGRNWrS


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