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
http://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 [EMAIL PROTECTED]
