Re: The bank fraud blame game

2007-07-02 Thread Anne Lynn Wheeler

Adam Shostack wrote:

I'd suggest starting from the deployment, training, and help desk
costs.  The technology is free, getting users to use it is not.  I
helped several banks look at this stuff in the late 90s, when cost of
a smartcard reader was order ~25, and deployment costs were estimated
at $100, and help desk at $50/user/year.


re:
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game

there was a detailed analysis of the 99/00 smartcard deployments ... looking 
at the most common causes for problems. this was overlapped with opinion
claimed to be widely held among consumer financial institutions, that it had 
been proven that smartcards were not practical in the consumer market segment.


for something of a lark, at the annual smartcard conference, i went around to
most of the booths asking people at the booth if they were 1) aware 
that the financial industry considered smartcard not practical in the

consumer market segment and 2) what was the cause of the majority of the
problems.

some of the major deployments selected to be pc/sc compliant ... which at the
time only supported serial port attachment ... and did not support USB 
plugplay.
It turned out that the vast majority of smartcard deployment problems in that 
time-frame
had to do with consumers trying to install serial port card readers, consumers
that couldn't find the serial port, serial port connections that conflicted with
something else, serial port conflicts, serial driver conflicts (large number of BSOD 
and consumers having to re-install their systems from scratch).


there was then a very complex and intricate series of negotiations getting
agreement to upgrade pc/sc to support USB plugplay (for starters, responses 
like why even bother since it had been proven already that smartcards weren't 
practical in the consumer marketplace ... ignoring for a moment that major
factor in the failures was the pc/sc serial port limitations) . 

There were also things like  alternative packaging ... USB keyboard with 
built-in smartcard reader, display,  and PIN-pad cut-out switch ... where 
keyboard incremental cost was more like $5  (but again, it required PC/SC 
to be upgraded to USB plugplay)


however, by that time, nearly every where you went, there were echos that it 
(some
deployment or another) had proven that smartcards were not practical in consumer 
environment. Note that it wasn't just consumer limited, there were instances where 
commercial  operations figured that it would be on the order of $500/PC to be able 
to handle PC/SC serial port smartcard reader attachments.


it was in the midst of these particular disasters that you also saw some of
the smartcard operating system projects being canceled (again the spreading
belief that smartcards were not practical in the consumer market place).
All of this can be pretty much put at the doors of the institutions failing
to understand some of the fundamental issues attempting to deploy serial-port
PC/SC in the PC market place of the time (and/or understand that large
driver behind doing the whole USB plugplay thing was the significant problem
and issues attempting to deal with the serial port implementation)

some number of past posts mentioning the whole PC/SC serial port problems
encountered with various attempts at smartcard deployments in the
PC/consumer marketplace
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's 
your private key
http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed 
Flowers
http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
http://www.garlic.com/~lynn/2002m.html#37 Convenient and secure eCommerce using 
POWF
http://www.garlic.com/~lynn/2002m.html#39 Convenient and secure eCommerce using 
POWF
http://www.garlic.com/~lynn/2003n.html#35 ftp authentication via smartcard

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


Re: The bank fraud blame game

2007-07-02 Thread Thor Lancelot Simon
On Sun, Jul 01, 2007 at 08:38:12AM -0400, Perry E. Metzger wrote:
 
 [EMAIL PROTECTED] (Peter Gutmann) writes:
  (The usage model is that you do the UI portion on the PC, but
  perform the actual transaction on the external device, which has a
  two-line LCD display for source and destination of transaction,
  amount, and purpose of the transaction.  All communications enter
  and leave the device encrypted, with the PC acting only as a proxy.
  Bill of materials shouldn't be more than about $20).
 
 I've been thinking this was the way to go for years now.

Who hasn't?  Oh, I'm sorry -- I meant to say: who, outside of the
set of producers and consumers of security snake oil aimed at
financial institutions, hasn't?

Regular readers will recall the SecurID discussion of about a
year ago, when an individual who appeared to be a paid consultant
to RSA vigorously put forth the notion that secure devices which
required the user to actually do something to authenticate a
transaction were _not_ what was needed -- to the shock and awe
of most readers of, and writers to, the thread here, at least
as I would summarize the discussion.

Thor

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


Re: The bank fraud blame game

2007-07-02 Thread Hal Finney
[EMAIL PROTECTED] (Peter Gutmann) writes:
 (The usage model is that you do the UI portion on the PC, but perform the
 actual transaction on the external device, which has a two-line LCD display
 for source and destination of transaction, amount, and purpose of the
 transaction.  All communications enter and leave the device encrypted, with
 the PC acting only as a proxy.  Bill of materials shouldn't be more than about
 $20).

In theory the TPM was supposed to allow this kind of thing.  The idea
was that the OS would support secure applets that could not be molested
by legacy software.  Only such an applet would have access to your
payment information.  Some specialized, perhaps customized screen would
be displayed by the applet to get you to authorize the final transfer.

This was one of the main goals of the TPM as I understood the concept.
Unfortunately everyone got focused on the DRM aspect and that largely
torpedoed the whole idea.  Still we might see it eventually.  Research
in this direction is still going on, particularly in IBM's Integrity
Measurement Architecture[1] and some of the new security extensions to
the Xen virtualization software[2].

Hal Finney

[1] 
http://domino.research.ibm.com/comm/research_people.nsf/pages/sailer.ima.html
[2] http://xensource.com/files/xs0106_security_print.pdf , also
http://www.hpl.hp.com/techreports/2007/HPL-2007-69.pdf

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


Re: The bank fraud blame game

2007-07-02 Thread Adam Shostack
On Sun, Jul 01, 2007 at 04:01:03PM -0400, Perry E. Metzger wrote:
| 
| Adam Shostack [EMAIL PROTECTED] writes:
|  On Mon, Jul 02, 2007 at 01:08:12AM +1200, Peter Gutmann wrote:
|   
|   Given that all you need for this is a glorified pocket calculator,
|   you could (in large enough quantities) probably get it made for 
|   $10, provided you shot anyone who tried to introduce
|   product-deployment DoS mechanisms like smart cards and EMV into
|   the picture.  Now all we need to do is figure out how to get there
|   from here.
| 
|  I'd suggest starting from the deployment, training, and help desk
|  costs.  The technology is free, getting users to use it is not.  I
|  helped several banks look at this stuff in the late 90s, when cost of
|  a smartcard reader was order ~25, and deployment costs were estimated
|  at $100, and help desk at $50/user/year.
| 
| Of course, given the magnitude of costs of fraud, and where it may be
| heading in the near term, the $50 a year may be well spent, especially
| if it could be cut to $25 with some UI investment. It is all a
| question of whether you'd rather pay up front with the security
| apparatus or after the fact in fraud costs...

It may be, indeed.  You're going (as Lynn pointed out in another post)
to be fighting an uphill battle against the last attempts.  I don't
think smartcards (per se) are the answer.  What you really need is
something like a palm pilot, with screen and input and a reasonably
trustworthy OS, along with (as you say) the appropriate UI investment.

Adam

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


Re: The bank fraud blame game

2007-07-02 Thread Florian Weimer
* Ian G.:

 Banks are the larger and more informed party.

But not as far as client-side fraudulent activity is concerned.  After
all, the attacked systems are not under their administrative control.

 They need to provide systems that are reasonable given the situation
 (anglo courts generally take this line, when pushed, I'm unsure what
 continental courts would do with that logic).

We have courts that are traditionally bank-friendly, and courts that
aren't.  While we do not heavily rely on case law, it's a bit of luck
which one sets the precedent (which will eventually help to shape
legislation).

And what's worse, the situation is so unstable that a case that gets
decided in favor of one party might actually end up shifting the risks
to the other party in the long run because the environment keeps
changing rapidly.

 Customers aren't in any position to dictate security requirements to
 banks.

And vice versa.

It might even happen that we see competion from foreign, EU-based
banks that offer transactions without the safeguards German banks have
agreed to among each other.  We'll see if this increase in convenience
turns out to be a major selling point.

 Unfortunately for the banks, there is a vast body of evidence that
 we knew and they knew or should have known that the PC was insecure
 [1].

I think the extent to which end users, hardware and software
manufacturers, and ISPs don't care about compromised machines was a
real surprise.  If there's malware on the PC, it's not just banking
that is affected.  You'd expect people to do something about it, but
no one does without significant external pressure.

And if you look closely at which attacks security experts predict (and
not just self-proclaimed ones!), and which actually materialize, there
are significant differences.  These differences are usually mulled
over by ambiguous terminology, but the gap is there.

 So, by fielding a system -- online commerce -- with a known
 weakness, they took responsibility for the fraud (from all places).

They didn't build the Internet, they didn't provide the PC and its
software, they don't even run the most-frequented online commerce
applications.  But in a moment of weakness, they started to take
responsibility.  And the real difficulties began.

For a rare security success story, look at how ISPs manage to sell a
completely insecure product which puts their customers at significant
risk, and take virtually no blame for it.  And technologically, banks
are not that different from mail providers.  They just pass around
messages.  Why should they be responsible for their content, if ISPs
aren't?

 Now they are in the dilemma.  The customer can't provide evidence of
 the fraud, because the system fielded doesn't support it (it's login
 authentication not transaction authorisation).

Non-digital crime faces the same problem.  You haven't got a
cryptographically secured audit trail, either.  But clues can still be
found.

 [1] To my knowledge, continental banks knew of the risks and acted in
 the 90s, then scaled it down because the risks proved overstated.
 Brit banks knew of the risks and didn't care.  American banks didn't
 care.

The American banking system is mainly protected by its obsolescence.
It's not an end-to-end transaction system, unlike the European ones.

 [2] Again, continental banks are shifting to SMS authorisation
 (dual-channel) ... Brit banks are unsure what to do ...

The new APACS standard should be a huge leap forward for the UK.
AFAIK, it includes the limited form of transaction signing that is
possible within the constraints.  Of course, it's still not foolproof,
but the non-fools can actually detect a compromised terminal.

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


Re: The bank fraud blame game

2007-07-02 Thread Florian Weimer
* Anne  Lynn Wheeler:

 In the mid-90s, financial institutions looking at the internet for
 online, commercial banking and cash management (i.e. business
 equivalent to consumer online banking) were extremely conflicted
 ... they frequently were almost insisting on their own appliance at
 the business (and low-end of SOHO at least overlaps high-end
 of consumer online banking).

Well, in 1994, German Postbank already had 300,000 online banking
customers.  (To put this into perspective, there are somewhere around
3 million online customers today, and this was well before the
Internet took off in Germany.)

On top of that, there were other forms of digital banking that were
mainly used by business customers, such as transactions submitted on
floppy disks.

 Various of the PC-based dedicated financial applications go to
 quite some lengths to compensate for kind of vulnerabilities
 typically associated with browser activity. For instance,
 instead of relying on a trusted third party to certify that
 some remote location really has a valid digital certificate,
 they have a trusted repository of valid financial institutions.

Oh really?

In Germany, early digital banking had no cryptographic protection at
all.  Integrity and confidentiality were inherited from the underlying
phone system.  There were no end-to-end digital signatures.  Nothing.
Just a one-time password for each transaction, but the password was
not tied to the transaction in any way.

 This has the added benefit of eliminating the horribly complex
 and vulnerable PKI-type of operation

Except that there aren't any attacks on the browser PKI.  That's part
of the reason why the certificate prices plummeted. 8-/

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


Re: The bank fraud blame game

2007-07-02 Thread Anne Lynn Wheeler

Florian Weimer wrote:


Oh really?

In Germany, early digital banking had no cryptographic protection at
all.  Integrity and confidentiality were inherited from the underlying
phone system.  There were no end-to-end digital signatures.  Nothing.
Just a one-time password for each transaction, but the password was
not tied to the transaction in any way.


This has the added benefit of eliminating the horribly complex
and vulnerable PKI-type of operation


Except that there aren't any attacks on the browser PKI.  That's part
of the reason why the certificate prices plummeted. 8-/



re:
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game

there had been lots of home banking with PCs starting in the 80s. these
were dial-up into private bank modem pools (both consumer and
business cash management). one of the trade-offs looking at
going to internet based operation is the enormous infrastructure
savings to financial institutions. 

in 1995, a presentation by one financial institutions figured that 
they were supporting something like 65 different software modem drivers 
(different modems, different operating systems, different platforms, 
etc). transitioning to internet met that they could eliminate all of 
that (lots of help desk, lots of serial port issues, lots of hardware

issues ... a much smaller precursor to the later smartcard PC/SC serial
port disaster).

they talked about what trade-offs were with any conversion to internet, 
the operating system vendors  and ISPs would  go to a common connectivity 
operation,  bearing the cost of all  the online connectivity ... amortized 
over a lot of online use (not just online  banking). This eliminated an
enormous cost for online banking. The downside was that the security issues 
significantly increased.


the dedicated financial applications have some similarities to
that earlier dial-up phone environment ... except they are using
something akin to a controlled SSL encrypted path (tunneled thru
the internet) where the remote PC application has preloaded information
about the financial institution's server (not needing traditional PKI 
trusted 3rd party certification authority to provide information about unknown

parties).

now with respect to weakness of using PKI for such purposes, i've contended 
in the past that the image/picture authentication helped increase the 
possibility that the consumer/client was dealing with valid financial 
institution (that they had previously registered the image/picture with).


in that sense, it can be viewed as countermeasure to common phishing attacks
... where clients are convinced to click on some field that takes their
browser to some webserver. Given that the attacker can supply both the
actual URL and the corresponding SSL digital certificate ... and majority
of clients have very weak binding between websites and the corresponding
URL (i.e. SSL PKI digital certificate is just checking that the webserver
contacted actually corresponds to the supplied URL)  then attackers
have found an enormous PKI weak link in the current way SSL is deployed 
(it relies on the user to provide the binding between the webserver

they think they are talking to and that webserver's URL ... where
SSL PKI is then only providing the binding between a URL and a webserver).

As a result, active MITM attacks have happened ... where consumer is 
convinced to click on a field purported to connect them to their

financial institution. The attack actually provides a URL to their
own webserver for which they have a valid SSL digital certificate ...
then they can transparently pass communication between the real
financial institution website and the consumer (with two different
SSL sessions connected at the attackers website) ... aka the image/picture
authentication stuff is to imcrease the sense of comfort a customer
would have that they are actually talking to their financial institution
(in view of all the SSL short-comings ... however, it doesn't actually
preclude the security attacks).

lots of past posts mentioning MITM-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

some specific past posts about MITM-attacks and bank site authentication
http://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private 
information to improve security
http://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL ... addenda 2
http://www.garlic.com/~lynn/aadsm26.htm#56 Threatwatch: MITB spotted: MITM over 
SSL from within the browser
http://www.garlic.com/~lynn/2007d.html#26 Securing financial transactions a 
high priority for 2007

part of this harks back to when were originally called 

RE: Free Rootkit with Every New Intel Machine

2007-07-02 Thread Ian Farquhar \(ifarquha\)
Dave Korn wrote:
 Ian Farquhar wrote:
 Maybe I am showing my eternal optimist side here, but to me, this is 
 how TPM's should be used, as opposed to the way their backers 
 originally wanted them used.  A removable module whose connection to a 
 device I establish (and can de-establish, assuming the presence of a 
 tamper-respondent barrier such as a sensor-enabled computer case to 
 legitimize that activity) is a very useful thing to me, as it 
 facilitates all sorts of useful applications.  [...]

 If you can remove it, what's to stop you plugging it into another machine and 
 copying all
 your DRM-encumbered material to that machine?

 It's supposed to identify the machine, not the user.  Sounds to me like what 
 you want is a 
 personally identifying cert that you could carry around on a usb key...

Nothing, but you missed my point.  I'm not interested in the DRM functionality, 
or user-removability.  My point was to look
beyond that original remit.

Specifically, a module which supports authenticated physical removal (with a 
programmed tamper response) *is* useful, especially
for server applications. (*)  Smartcards and secure USB devices might be 
useful for other applications, but not the one I was
describing, because they lack a tamper response.

Note I'm also saying programmable tamper response.  Although I like the idea 
of wiping keys on tamper response, it's not
necessarily the ideal response.  A better possibility (in certain 
circumstances) is the device entering a lockdown mode with
selected and modelled reduced functionality.  Examples of such circumstances 
are where the tamper might be triggerable
maliciously, thus facilitating a DoS attack against the service. 

Ian.

(*) And isn't it interesting how so many desktop systems are now starting to 
run application mixes which really look like
servers?

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


Re: TPM, part 2

2007-07-02 Thread Anne Lynn Wheeler

Peter Gutmann wrote:

I have a friend who implemented a basic trusted-boot mechanism for a student
project, so we have evidence of at least one use of a TPM for TC, and I know
some folks at IBM Research were playing with one a few years ago, so that's at
least two users so far.  Anyone else?


as i've mentioned before ... we looked at somewhat similar hardware solution
(but much simpler) for the original acorn (ibm/pc code name), primarily as software piracy 
countermeasure  ... but the tamper resistant technology state of the art at the time was 
way too expensive ... and investigation was dropped. what was seen during
the 80s were things like those specially encoded floppy disks ... that had 
to be inserted when you started the application ... a couple past posts/references:

http://www.garlic.com/~lynn/2006p.html#41 Device Authentication - The answer to 
attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/aadsm27.htm#9 Enterprise Right Management vs. 
Traditional Encryption Tools
http://www.garlic.com/~lynn/2007m.html#20 Patents, Copyrights, Profits, Flex 
and Hercules

in the late 90s i would periodically chide the TPM folks about what
they were doing ... and at an assurance talk i gave in the trusted computing
track at intel developers forum (spring 2001), i chided the guy running
the effort (was sitting in the front row) that it was nice to see that 
over the previous couple yrs that TPM had started to look more  more

like the AADS chip strawman. his retort was something about it being
because I didn't have a committee of couple hundred people helping
me with (my) chip design. 


misc. past posts mentioning aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

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


Re: The bank fraud blame game

2007-07-02 Thread Leichter, Jerry
| |   Given that all you need for this is a glorified pocket
| |   calculator, you could (in large enough quantities) probably get
| |   it made for  $10, provided you shot anyone who tried to
| |   introduce product-deployment DoS mechanisms like smart cards and
| |   EMV into the picture.  Now all we need to do is figure out how
| |   to get there from here.
| | 
| |  I'd suggest starting from the deployment, training, and help desk
| |  costs.  The technology is free, getting users to use it is not.  I
| |  helped several banks look at this stuff in the late 90s, when cost
| |  of a smartcard reader was order ~25, and deployment costs were
| |  estimated at $100, and help desk at $50/user/year.
| | 
| | Of course, given the magnitude of costs of fraud, and where it may
| | be heading in the near term, the $50 a year may be well spent,
| | especially if it could be cut to $25 with some UI investment. It is
| | all a question of whether you'd rather pay up front with the
| | security apparatus or after the fact in fraud costs...
| 
| It may be, indeed.  You're going (as Lynn pointed out in another post)
| to be fighting an uphill battle against the last attempts.  I don't
| think smartcards (per se) are the answer.  What you really need is
| something like a palm pilot, with screen and input and a reasonably
| trustworthy OS, along with (as you say) the appropriate UI investment.
You do realize that you've just come down to what the TPM guys want to
build?  (Of course, much of the driving force behind having TPM comes
from a rather different industry.  We're all happy when TPM can be
used to ensure that our banking transactions actually do what the bank
says it will do for a particular set of instructions issued by us and
no one else, not so happy when they ensure that our music transactions
act the same way)

Realistically, the only way these kinds of devices could catch on would
be for them to be standardized.  No one would be willing to carry one
for their bank, another for their stock broker, a third for their
mortgage holder, a fourth for their credit card company, and so on.
But once they *are* standardized, almost the same potential for
undesireable uses appears as for TPM's.  What's to prevent the movie
download service requiring that you present your Universal Safe Access
Fob before they authorize you to watch a movie?  If the only significant
differences between this USAF and TPM is that the latter is more
convenient because more tightly tied to the machine, we might as well
have the convenience.

(This is why I find much of the discussion about TPM so surreal.  The
issue isn't the basic technology, which one way or another, in some form,
is going to get used.  It's how we limit the potential misuses)

-- Jerry

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


Re: The bank fraud blame game

2007-07-02 Thread Stephan Neuhaus

Peter Gutmann wrote:

Given that all you need for this is a glorified pocket calculator, you could
(in large enough quantities) probably get it made for  $10, provided you shot
anyone who tried to introduce product-deployment DoS mechanisms like smart
cards and EMV into the picture.


That seems exactly to be the problem.  Germany's e-health card would be 
a prime candidate for technology that could boost the use of such 
pinpads, but unfortunately the card will contain a smart card.  (The 
device has a host of other problems too, don't get me started.)


Fun,

Stephan

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


Re: The bank fraud blame game

2007-07-02 Thread Peter Gutmann
Adam Shostack [EMAIL PROTECTED] writes:

I'd suggest starting from the deployment, training, and help desk costs.  The
technology is free, getting users to use it is not.  I helped several banks
look at this stuff in the late 90s, when cost of a smartcard reader was order
~25, and deployment costs were estimated at $100, and help desk at
$50/user/year.

Banks here have been using SMS-based transaction verification for a few years
now (although not done very well, sigh) without, apparently, any real problems
(I've been trying to get figures for per-transaction costs out of them for a
while now, so far without any success).  Since the SMS-based system is just a
labour-intensive way of doing what I was proposing but using a cellphone
instead of a dedicated device, my guess is that the overhead won't be that
bad.  If it was, the banks wouldn't be doing it now :-).

(Using smart cards as a yardstick isn't terribly useful, as I mentioned in my
previous message they're really a deployment DoS mechanism, not a solution).

I don't think smartcards (per se) are the answer.  What you really need is
something like a palm pilot, with screen and input and a reasonably
trustworthy OS, along with (as you say) the appropriate UI investment.

Smart cards are part of the problem set, not the solution set - they're just
an expensive and awkward distraction from solving the real problem.  What I
was suggesting (and have been for at least ten years :-) is a small external
single-function device (no need for an OS) that can't be compromised by
malware because there's no attack vector for the malware to get at it.

Peter.

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


TPM hacking

2007-07-02 Thread Sean W. Smith
Seeing as how there are are some rumors about other attacks coming  
from BlackHat, I thought we should publicize ours a bit:


A 3 piece of wire does the job.  More info (and a link to a YouTube  
demo) at:


www.cs.dartmouth.edu/~pkilab/sparks/

--Sean

Sean W. Smith   [EMAIL PROTECTED]  www.cs.dartmouth.edu/~sws/
Associate Professor, Department of Computer Science, Dartmouth  
College, Hanover NH USA




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


Re: The bank fraud blame game

2007-07-02 Thread Nicholas Bohm
Perry E. Metzger wrote:
 Adam Shostack [EMAIL PROTECTED] writes:
 On Mon, Jul 02, 2007 at 01:08:12AM +1200, Peter Gutmann wrote:
 Given that all you need for this is a glorified pocket calculator,
 you could (in large enough quantities) probably get it made for 
 $10, provided you shot anyone who tried to introduce
 product-deployment DoS mechanisms like smart cards and EMV into
 the picture.  Now all we need to do is figure out how to get there
 from here.
 I'd suggest starting from the deployment, training, and help desk
 costs.  The technology is free, getting users to use it is not.  I
 helped several banks look at this stuff in the late 90s, when cost of
 a smartcard reader was order ~25, and deployment costs were estimated
 at $100, and help desk at $50/user/year.
 
 Of course, given the magnitude of costs of fraud, and where it may be
 heading in the near term, the $50 a year may be well spent, especially
 if it could be cut to $25 with some UI investment. It is all a
 question of whether you'd rather pay up front with the security
 apparatus or after the fact in fraud costs...

That is why efforts by banks to shift the risk to the customer are
pernicious - they distort the incentive the bank ought to have to get
the security right.

Nicholas Bohm
-- 
Salkyns, Great Canfield, Takeley,
Bishop's Stortford CM22 6SX, UK

Phone  01279 870285(+44 1279 870285)
Mobile  07715 419728(+44 7715 419728)

PGP public key ID: 0x899DD7FF.  Fingerprint:
5248 1320 B42E 84FC 1E8B  A9E6 0912 AE66 899D D7FF

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


Re: The bank fraud blame game

2007-07-02 Thread Anne Lynn Wheeler

Peter Gutmann wrote:

Smart cards are part of the problem set, not the solution set - they're just
an expensive and awkward distraction from solving the real problem.  What I
was suggesting (and have been for at least ten years :-) is a small external
single-function device (no need for an OS) that can't be compromised by
malware because there's no attack vector for the malware to get at it.


there is an interesting side story to this involving certification, common 
criteria,
protection profiles, etc.

possibly the majority of the smartcard protection profiles have to do with all 
the
problems allowing software/application to be loaded. on the other hand, you can
get a common criteria evaluation done on the basic chip ... w/o any application
loading ... and being able to show a much higher security level ... than might 
be
possible with any application actually loaded.

one of the problems i ran into getting higher than eal4+ for aads chip strawman
... was since everything was built into the silicon at manufacturing time, and 
nothing could be subsequently loaded ... all the crypto had to also be resident
in the silicon. 


one of the original objectives given for the aads chip strawman was being able
to do digital signature in contactless form factor within transit gate elapsed
time requirements (very low power and very fast) ... which eventually fell to
doing ec/dsa ... and i couldn't get an protection profile definition for ec/dsa
higher than eal4+.  similar chips ... w/o anything loaded had been able to
get eal5+ evaluation (or better) ... but since ec/dsa was built into the chip 
silicon,
it was only possible to get eal4+.

the other criteria for aads chip strawman was extremely aggressive cost 
reduction;
i had joked i was taking a $500 milspec part, cost reducing by 2-3 orders of
magnitude and at the same time increasing the integrity. part of the aggressive
cost reduction was choosing a single function (something you have 
authentication
via chip digital signature) that could be used in a broad range of applications 
...
and eliminate everything else.

misc. aads
http://www.garlic.com/~lynn/x959.html#aads

other posts in this thread:
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game

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


Re: The bank fraud blame game

2007-07-02 Thread Adam Shostack
On Sun, Jul 01, 2007 at 11:09:16PM -0400, Leichter, Jerry wrote:
| | |   Given that all you need for this is a glorified pocket
| | |   calculator, you could (in large enough quantities) probably get
| | |   it made for  $10, provided you shot anyone who tried to
| | |   introduce product-deployment DoS mechanisms like smart cards and
| | |   EMV into the picture.  Now all we need to do is figure out how
| | |   to get there from here.
| | | 
| | |  I'd suggest starting from the deployment, training, and help desk
| | |  costs.  The technology is free, getting users to use it is not.  I
| | |  helped several banks look at this stuff in the late 90s, when cost
| | |  of a smartcard reader was order ~25, and deployment costs were
| | |  estimated at $100, and help desk at $50/user/year.
| | | 
| | | Of course, given the magnitude of costs of fraud, and where it may
| | | be heading in the near term, the $50 a year may be well spent,
| | | especially if it could be cut to $25 with some UI investment. It is
| | | all a question of whether you'd rather pay up front with the
| | | security apparatus or after the fact in fraud costs...
| | 
| | It may be, indeed.  You're going (as Lynn pointed out in another post)
| | to be fighting an uphill battle against the last attempts.  I don't
| | think smartcards (per se) are the answer.  What you really need is
| | something like a palm pilot, with screen and input and a reasonably
| | trustworthy OS, along with (as you say) the appropriate UI investment.
|
| You do realize that you've just come down to what the TPM guys want to
| build?  (Of course, much of the driving force behind having TPM comes
| from a rather different industry.  We're all happy when TPM can be
| used to ensure that our banking transactions actually do what the bank
| says it will do for a particular set of instructions issued by us and
| no one else, not so happy when they ensure that our music transactions
| act the same way)

I don't believe that's so.  The TPM guys want to add a variety of
controls to extant PC designs to make them secure.  I want to add a
new device to the mix.

| Realistically, the only way these kinds of devices could catch on would
| be for them to be standardized.  No one would be willing to carry one
| for their bank, another for their stock broker, a third for their
| mortgage holder, a fourth for their credit card company, and so on.
| But once they *are* standardized, almost the same potential for
| undesireable uses appears as for TPM's.  What's to prevent the movie
| download service requiring that you present your Universal Safe Access
| Fob before they authorize you to watch a movie?  If the only significant
| differences between this USAF and TPM is that the latter is more
| convenient because more tightly tied to the machine, we might as well
| have the convenience.

Fair questions.  I'm sure I don't have answers.

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