The bank fraud blame game

Sun Jul 1 19:33:59 EDT 2007

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 into consult
with this small client/server startup that wanted to do payments on
their servers ... they had this technology called SSL they wanted
to use and it has since come to be frequently called electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

the end-to-end security "assumptions" at the time was that the user
would type into the browser, the URL of the website they wanted to
connect to. This created the trusted binding between the website the
user wanted to talk to and the URL. Then the browser using SSL, digital
certificates, PKI, etc ... would validate the correspondence between
the URL and the webserver that was actually contacted (two part trust
operation, both required).

however, fairly early in the deployment, merchants found that using
SSL for the whole shopping experience cut there thruput by 90-90 percent.
as a result, they cut SSL use back to just the part for payment.
Now the user can enter a URL ... and it isn't validate with SSL ...
so the user can be talking to an attackers website. Then when they
go to pay/checkout ... they click on a button (provided by potential
fraudulent website). The button provides the URL for the checkout
portion ... allowing an attacker to provide both the URL and an
digital certificate that corresponds to that URL.

Now longer is SSL being used to provide the correspondence between
the webserver that the user thinks they are talking to and the webserver
they are actually talking to ... the user is getting both the
URL and the digital certificate off the net ... so all an attacker
has to show that the URL they claim to be is the URL that they
have a valid digital certificate for. 

lots of past posts about SSL (and effectively SSL digital certificates
turning into a "comfort" item as opposed to a real security feature)
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

For other topic drift, in the mid-90s at one of the large security
conferences (in the US), one of the large German banks gave a talk on relying
party only digital certificates ... lots of past posts mentioning
RPO certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

They had realized that the X.509 identity digital certificates from the early
90s and potentially overloaded with enormous amounts of personal information ...
represented significant privacy and liability issues. As a result, they
had retrenched to RPO-certificates containing little more than an account
number (or other kind of record locater) and public key ... if you actually
wanted to do something ... it was necessary to read the information from
the correct account. It wasn't just large German financial institutions that
had come to this realization ... numerous financial institutions were 
retrenching from the x.509 identity digital certificates of the early 90s.

Note, however, examining all the business processes that would make use of
RPO-certificates ... we were able to demonstrate that it was trivial to
include the public key in the specified account record ... making the 
associated PKI and digital certificates redundant and superfluous.

This also significantly influenced our work on the X9.59 financial standard
in the X9A10 financial standard working group (which in the mid-90s had been
given the requirement to preserve the integrity of the financial infrastructure
for all retail payments)
http://www.garlic.com/~lynn/x959.html#x959

It wasn't just that the RPO-certificates were redundant and superfluous. The
typical RPO-certificates being tested in that time-frame were contributed
enormous payload bloat (PKI and digital certificate payload overhead was
on the order of one hundred times larger than the typical financial transaction
size). misc. past posts mentioning the enormous payload bloat of redundant
and superfluous digital certificates
http://www.garlic.com/~lynn/subpubkey.html#bloat

In the same timeframe as x9a10 work on x9.59, the X9F committee was attempting
to take another approach. They had a standard work item for "compressed" digital
certificates (objective to try and get payload bloat of RPO-certificates and PKI
overhead down to possibly only 5-10 times larger than the base financial transaction 
size).

One of their suggested approaches ... was that all fields that were common to
an issuers RPO-certificate would be eliminated ... i.e. only the fields that
were unique to every RPO-certificate would be included. I had a slightly different
suggestion ... instead eliminate all fields in the RPO-certificate that the
financial institution already had on file for the entity. Since by definition,
it could be shown that the financial institution already had all fields 
(if nothing else from having issued the RPO-certificate in the first place),
then it would be possible to eliminate all fields, reducing an RPO-certificate
to zero bytes. 

So as an alternative to deploying a certificateless public key infrastructure
http://www.garlic.com/~lynn/subpubkey.html#certless

it would be possible to deploy a fully functional PKI operation that depended
on attaching zero byte digital certificates to every transaction (which would
also address the enormous PKI payload bloat). some old posts discussing the
enormous advantages of a PKI with zero byte digital certificates
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com