Status of SRP

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com