New ISO standard aims to ensure the security of financial transactions
on the Internet
http://continuitycentral.com/news02582.htm
from above:
ISO 21188:2006, ‘Public Key Infrastructure for financial services –
practices and policy framework’, offers a set of guidelines to assist
risk managers, business managers and analysts, technical designers and
implementers and operational management and auditors in the financial
services industry.
... snip ...
my two bits ... in part, in light of recent pin&chip vulnerability thread
another metaphor for viewing the session authentication paradigm is that
they tend to leave the actual transaction naked and vulnerable.
we had worked on the original payment gateway for what become to be
called e-commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
which we also assert can be considered the first SOA implementation
http://www.garlic.com/~lynn/2006l.html#38 Token-ring vs Ethernet - 10
years later
to some extent part of the transaction vulnerability analysis for x9.59
transactions in the mid-90s was based on analysis and experience with
the original payment gateway implemented with session oriented paradigm.
http://www.garlic.com/~lynn/x959.html#x959
work on x9.59 in the mid-90s, did what very few other protocols did,
defined end-to-end transaction strong authentication. many of the other
protocols would leave the transaction naked and vulnerable at various
steps in the processing.
session oriented protocols leaving the actual transaction naked and
vulnerable (or the actual transaction not having complete end-to-end
transaction strong authentication and therefor naked and vulnerable for
at least some part of the processing) ... implies that the complete,
whole end-to-end business process has to be heavily armored and secured.
Minor chinks in the business armoring will expose the naked transaction
to potentional attack and fraud.
if outsider attacks aren't enuf, naked transactions are also extremely
vulnerable to insider attacks. nominally, transactions will be involved
in a large number of different business processes ... exposing them to
insider attacks at every step. end-to-end transaction strong
authentication armors the actual transaction (avoiding leaving the
transaction naked and vulnerable at vast array of processing steps). the
naked transaction paradigm also contributes to the observation that
something like seventy percent of fraud in such environments involve
insiders.
end-to-end transaction strong authentication (armoring the actual
transaction) then also alleviates the need for enormous amounts of total
business process armoring (where absolutely no chinks in the armor can
be allowed ... which is necessary for protecting naked and vulnerable
transactions ... which don't have end-to-end transaction strong
authentication).
the x9a10 working group (for what become the x9.59 financial standard)
had been given the requirement to preserve the integrity of the
financial infrastructure for all retail payments. this met not only
having countermeasures to things like replay attacks (static data that
could be easily skimmed), but also having end-to-end transaction strong
authentication (eliminating the vulnerabilities associated with having
naked and vulnerable transactions at various points in the infrastructure).
part of the x9.59 financial standard for all retail payments in armoring
and protecting transactions included the business rule that account
numbers used in x9.59 transactions could not be used in transactions
that didn't have end-to-end transaction strong authentication. this
eliminated the problem with knowledge leakage of the account number
representing a vulnerability (i.e. a naked account number was no longer
vulnerable for use in fraudulent transactions).
part of the theme of the post on security proportional to risk is that
if the individual transactions aren't armored then it can be
extraordinarily expensive to provide absolutely perfect infrastructure
armoring to protect naked and vulnerable transactions
http://www.garlic.com/~lynn/2001h.html#61
part of the issue with some of the payment oriented protocols in the
mid-90s looking at providing end-to-end strong authentication based on
digital signature paradigm was the mistaken belief regarding appending
digital certificates as part of the implementation. typical payment
transaction is on the order of 60-80 bytes. the various payment
protocols from the period with appended digital certificates had a
payload bloat of 4k to 12k bytes (or a payload bloat of one hundred
times). it was difficult to justify an enormous end-to-end payload bloat
of one hundred times for a redundant and superfluous digital
certificate, so the protocols tended to strip the digital certificate
off, leaving the transaction naked and vulnerable during subsequent
processing. of course this was before I had demonstrated that it was
possible to compress appended digital certificates to zero bytes
(opening the way for x9.59 transactions with end-to-end strong
authentication based on digital signatures).
rather than viewing x9.59 as using certificateless digital signatures
for end-to-end transaction strong authentication
http://www.garlic.com/~lynn/subpubkey.html#certless
just consider that x9.59 has appended compressed zero byte digital
certificates to address the severe payload bloat problem
the issue of SDA (static data authentication vulnerable to replay
attacks) or DDA (countermeasure to replay attacks) is somewhat
independent of using a session oriented implementation (and having naked
and vulnerable transactions at various points in the infrastructure):
http://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN
Security Flaw
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN
Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#0 FraudWatch - Chip&Pin, a new
tenner (USD10)
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN
Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To
DDA EMV Cards
http://www.garlic.com/~lynn/aadsm24.htm#3 FraudWatch - Chip&Pin, a new
tenner (USD10)
http://www.garlic.com/~lynn/2006l.html#27 Google Architecture
http://www.garlic.com/~lynn/2006l.html#32 Google Architecture
http://www.garlic.com/~lynn/2006l.html#33 Google Architecture
http://www.garlic.com/~lynn/2006l.html#37 Google Architecture
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
