massive data theft at MasterCard processor

[Anne & Lynn Wheeler]

Anne & Lynn Wheeler wrote:
> as referenced in the above ... x9.59
> http://www.garlic.com/~lynn/index.html#x959
> 
> has countermeasure against the harvesting vulnerability (w/o
> requiring any encryption) which is so attractive to attackers because
> the return is so enormous for the amount of effort
> http://www.garlic.com/~lynn/subpubkey.html#harvest

note that while x9.59 allows for digital signature (as method of
strong-authentication) ... and even co-signing by both the consumer and
the terminal ... it doesn't mandate certificate-based operation and
allows for certificate-less digital signature authentication.
http://www.garlic.com/~lynn/subpubkey.html#certless

we had worked on the original payment gateway for what was becoming
e-commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

before starting in the x9a10 financial standards working group on x9.59
standard
http://www.garlic.com/~lynn/index.html#x959

in that time frame there were some number of specifications for
financial transactions that involved digital signatures and mandated a
fairly large collection of digital certificates and pki.

the financial industry in the mid-90s was one of the industries that was
starting to realize that the x.509 certificates, somewhat from the early
90s, representing significant privacy and liability issues ...
especially when grossly overloaded with personal information.

they had retrenched to relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

which effectively bound a public key to an account number or some other
form of database lookup value (where the real and relavant information
was actually stored). note that it was relatively trivial to show that
such digital certificates were redundant and superfluous (repeatedly
sending back database lookup value to the institution that had issued
the certificate and had direct access to all the real information).

the other issue we saw with some of the financial transactions mandating
digital certificates (especially redundant and superfluous
relying-party-only certificates) was the enormous payload bloat in
typical payment network transaction. A typical payment network
transaction has been on the order of 60-80 bytes ... the typical
relying-party-only digital certificate for these programs ran 4k to 12k
bytes ... which represented an enormous payload bloat of a factor of one
hundred times.

Some of the programs realizing that it really wasn't practical to
transmit such a redundant and superfluous digital certificate over the
typical payment network ... were having an internet boundary gateway
validate any digital signature (with the public key in the digital
certificate) ... and then transmitting a normal payment network
transaction with simply a bit turned on indicating if the digital
signature had verified.

Besides violating kindergarten security 101 regarding end-to-end
security (or because of it) ... there was an ISO standards meeting where
a business person from one of the payment networks gave statistics on
there being quite a few payment transactions flowing thru the network
with the digital signature verified flag turned on ... and they could
prove that there hadn't been any digital signature technology involved
(one possibly motivation given was that they were talking about lowering
the discount rate for digital signature verified transactions based on
presumption of lower fraud rate). The scenario is that the consumer's
issuing bank is the financial responsible party ... and fundamental
end-to-end security principles would dictate that the responsible party
for authorizing the transaction should also be the responsible party for
authenticating the transaction (rather than possible organizations that
might have interests quite different from that of the consumer's issuing
financial institution).

A side issue with some of the payment digital signature specifications
from the period was that they provided no countermeasure for the growing
harvesting/skimming problem ... aka the sam PAN in a digital signed
transaction could be harvested and used in a non-authenticated transaction
http://www.garlic.com/~lynn/subpubkey.html#harvest


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