Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]

2002-09-17 Thread Ted Lemon

 Relevence to the Pd debate is that banks may in future insist on remote
 attestation of users' software (however practically possible that is) 
 so
 that they can attempt to dump yet more liability on their users 
 (Ladies and
 gentlemen of the jury, Mr Doe's claim that he did not authorise this
 transfer to a Caribbean account is obviously fraudulent as his Fritz 
 chip
 proved to us that his system had not been compromised...)

Banks typically aren't that sophisticated.   Demand for this capability 
probably will not materialize in time to save Pd, although there are 
probably people working for banks who will claim that they want it.


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



Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]

2002-09-17 Thread Anne Lynn Wheeler

At 01:07 PM 9/17/2002 -0700, [EMAIL PROTECTED] wrote:
As far as I know, banks assume that a certain percentage of their 
transactions will be bad and build that cost into their business 
model.  Credit and ATM cards and numbers are as far from secure as could 
be, far less secure than somebody doing online transactions from a Wintel 
machine on an unencrypted connection, let alone an encrypted one.  Until 
somebody takes full advantage of the current system and steals a few 
trillion dollars in one day, the problems are easier to deal with than a 
solution.  Until that happens, there's no reason for banks to go through 
the pain of dealing with or requiring Pd.

-Jon Simon

note that EU finread standard attempted to address some of this. an 
external (secure, finread) token acceptor device with secure display and 
secure pin entry. The hardware token is used to sign the (financial) 
transaction  PIN code is entered into the finread device and goes 
directly to the hardware token (w/o passing thru the PC). Critical pieces 
of the transactions passes thru the finread device on the way to the 
(signing hardware token) and is displayed on the secure display ... which 
then requires the PIN to be entered to confirm the transaction.

There is the issue of 3-factor authentication

* something you have (hardware token)
* something you know (pin)
* something you are (biometrics in addition to /or in place of PIN)

besides the straight-forward use of signatures to authenticate the source 
of the transaction ... there is the nominal legal requirement associated 
with physical signatures ... i.e. did you intend to sign what you signed 
aka is what you see what you signed ... and do you confirm that you 
actually want the hardware token to sign what you see.

A lot of digital signature seems to address the technology part of 
authentication ... and then sometimes (just because the term signature is 
used as part of the description of the technical procedure) that all 
technical implementations of the process referred to as digital signature 
is legally equivalent to physical signatures (even when no aspects of 
intention have been satisfied).

random past finread  intention posts:
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, 
here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative 
to PKI?
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, 
or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during 
ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/2000.html#0 2000 = millennium?
http://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
http://www.garlic.com/~lynn/2000f.html#79 Cryptogram Newsletter is off the 
wall?
http://www.garlic.com/~lynn/2001f.html#39 Ancient computer humor - DEC WARS
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#51 future of e-commerce
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001j.html#46 Big black helicopters
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral 
infection?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001n.html#70 CM-5 Thinking Machines, 
Supercomputers
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security 
requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security 
requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet 
Banking
http://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet 
Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#13 Biometric authentication for 
intranet websites?
http://www.garlic.com/~lynn/2002l.html#24 Two 

Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]

2002-09-17 Thread R. A. Hettinga

At 1:07 PM -0700 on 9/17/02, [EMAIL PROTECTED] wrote:


 As far as I know, banks assume that a certain percentage of their
 transactions will be bad and build that cost into their business
 model.  Credit and ATM cards and numbers are as far from secure as
 could be, far less secure than somebody doing online transactions
 from a Wintel machine on an unencrypted connection, let alone an
 encrypted one.  Until somebody takes full advantage of the current
 system and steals a few trillion dollars in one day, the problems
 are  easier to deal with than a solution.  Until that happens,
 there's no  reason for banks to go through the pain of dealing with
 or requiring  Pd.

I wouldn't go that far. While Pd. -- and a certain long-term
ejaculative (look it up...) denizen of my kill-file -- is pretty much
a disingenuous shuck, greed is an amazing thing. The lowest cost
producer of anything, transactions, say, will not only make more
money than its competitors, but they will also *survive* longer than
anyone else. To quote, um, Stalin, quantity has a quality all its
own.


So, if strong financial cryptography gives us the lowest
*risk-adjusted* cost per transaction by some very large amount, the
market will adopt it just as quickly as if confronted with a threat
that only strong cryptography can remedy.

As software (in the http://www.nobel.se/economics/laureates/1992/
Gary Becker sense, things that can be more or less perfectly copied)
and wetware (valuable opinion, for lack of a better word) become more
important compared to hardware (stuff, discovered, extracted, or
built), the more valuable strong, secure, (geodesic :-)) networks and
(bearer :-)) financial cryptography becomes.



Cheers,
RAH




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