James A. Donald wrote:
> The concept of trusted computing is an attempt to
> address this problem - each application has exclusive
> access to certain data, a trusted path to interact with
> the user, and the ability to prove to servers what code
> is being executed on the client.
so they aren't exactly unrelated.
re:
http://www
.garlic.com/~lynn/aadsm23.htm#45 Status of SRP
http://www
.garlic.com/~lynn/aadsm23.htm#49 Status of SRP
http://www
.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
http://www
.garlic.com/~lynn/aadsm23.htm#53 Status of SRP
the financial standards x9a10 working group had been given
the
requirement to preserve the integrity for all retail
payments. the
result was the x9.59 payment standards for all retail
payments.
http://www
.garlic.com/~lynn/x959.html#x959
part of x9.59 retail payment standard requires the
transaction to be
authenticated. another part of the x9.59 retail payment
standard
requires that the account number in x9.59 retail payments
can't be used
in non-authenticated transactions. it as been recognized for
a long time
that a major source of account financial fraud has been the
data breaches
ht
tp://www.garlic.com/~lynn/subpubkey.html#harvest
and resulting fraudulent use of account numbers ... this is
somewhat my
old posting on security proportional to risk
http://www.
garlic.com/~lynn/2001h.html#61
in effect, account numbers have been overloaded. on one
hand, knowledge
of account numbers have been sufficient for doing fraudulent
transactions. as a result they have to be treated as shared
secrets,
kept confidential and never divulged. on the other hand,
account numbers
are required in a large number of business process as the
fundamental
cornerstone for transaction execution ... and are required
to be widely
available. as a result of these totally opposing
requirements, i've
periodically observed that the planet could be buried under
miles of
cryptography used in hiding account number, and it would
still be unable
to prevent leakage of account numbers. the x9.59 business
rule
recognizes this and changes the paradigm, eliminating the
severe
financial fraud vulnerability associated with divulging
account numbers
(and/or data breaches involving account numbers).
another part of x9.59, in addition to providing for
transaction digital
signature as part of transaction authentication (and trying
to close
some of the barn door with the overloaded requirements
placed on account
numbers) was allowing for a second digital signature by the
environment
that the transaction originated in. this would provide the
relying party
additional information for performing risk assessment
related to
authorizing the transaction.
so later when this software company wanted to come up with
something for
content providers, they hired the chair of the x9a10
financial standards
working group to move to redmond to be director of
development.
for other drift on trusted computing ... there are
capability based
operating systems ... current example is capros ... which
was spawned
from eros, which was sort of spawned from keykos, which was
spawned from
gnosis ... recent post mentioning some capros, eros, keykos,
gnosis, et
all (and other related lore regarding secure and/or
capability-based
operating systems ... going back to deployments by
commercial
time-sharing service bureaus in the late 60s and their
connections to
some of the current efforts ... as well as connections to
what i was
doing as an undergraduate in the 60s)
http://www.
garlic.com/~lynn/2006k.html#37
------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomo metzdowd.com
|