Misc AADS & X9.59 Discussions

AADS Postings and Posting Index,
next, previous - home

Identity Fraud costs Austrilia AU$1 billion a year
FAQ: e-Signatures and Payments
Electronic Safety and Soundness: Securing Finance in a New Age
Is Time Right For Micropayments
UBL proceeds for e-commerce
DOD prepares for credentialing pilot
ATM Fraud, Banking Your Money
The Digital Insider: Backdoor Trojans ... fyi
example: secure computing kernel needed
example: secure computing kernel needed
Difference between TCPA-Hardware and a smart card (was: example:secure computing kernel needed)
Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
The PAIN mnemonic
Non-repudiation (was RE: The PAIN mnemonic)
Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
Non-repudiation (was RE: The PAIN mnemonic)
Non-repudiation (was RE: The PAIN mnemonic)
Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
Non-repudiation (was RE: The PAIN mnemonic)
Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before

Identity Fraud costs Austrilia AU$1 billion a year

From: Lynn Wheeler
Date: 11/13/2003 09:34 AM
To: internet-payments <internet-payments@xxxxxxxx>
Subject: Identity Fraud costs Austrilia AU$1 billion a year

http://www.zdnet.com.au/newstech/security/story/0,2000048600,20280888,00.htm
Identity fraud costs Australia AU$1 billion a year
By Staff writers, ZDNet Australia
12 November 2003

Identity fraud cost the Australian community AU$1.1 billion in 2001/02, according to a report released by a senior Minister who also acknowledged the rapid subsequent growth of the problem.

The Minister for Justice and Customs, Senator Chris Ellison, said the report -- compiled by the Securities Industry Research Centre of the Asia Pacific -- pinpointed identity theft's involvement in criminal and terrorist activity worldwide.

... snip ...

FAQ: e-Signatures and Payments

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 11/14/2003 10:44 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>
Subject: Re: FAQ: e-Signatures and Payments

somewhat related to previous mention in this thread regarding simple security principles, KISS, complexity, etc. started in a thread related to key sizes, performance, and then wandered into other vulnerabilities:
https://www.garlic.com/~lynn/2003o.html#5 performance vs. key size
https://www.garlic.com/~lynn/2003o.html#6 performance vs. key size

the above specifically was with regard to buffer overflow vulnerability, and references some historical archeology
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation

the above specifically highlights three sections from the mentioned paper:
2.2 Security as Standard Product Feature
2.3 No Buffer Overflows
2.4 Minimizing Complexity

I'm slightly partial to this ... although I wasn't directly involved in the above work .... it was going on the 5th floor and I was located on the 4th floor. a somewhat related thread from cryptography mailing list:
https://www.garlic.com/~lynn/aadsm15.htm#23

Electronic Safety and Soundness: Securing Finance in a New Age

Refed: **, - **, - **, - **

From: Lynn Wheeler
Date: 11/17/2003 08:22 PM
To: "'internet-payments'" <internet-payments@xxxxxxxx>
Subject: Electronic Safety and Soundness: Securing Finance in a New Age

from the world bank site:
http://www1.worldbank.org/finance/
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/Searchresults1?openform
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/Searchresults1?openform&queryBanking+Systems,E-Security/E-Finance,Payments+SystemstypePublicationstopicsortDate

Electronic Safety and Soundness: Securing Finance in a New Age

Thomas Glaessner, Tom Kellermann, and Valerie McNevin (October 2003) This Monograph focuses on the sustainable development of e-finance and e-commerce. It raises awareness on the risks involved, as well as offers recommendations on how to mitigate these cyber-risks so that the shift to electronic financial services is conducted in a safe and sound manner. This paper and its technical annexes identify and discuss four key pillars that are necessary to foster a secure electronic environment and a sustainable global financial sector.
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/(attachmentweb)/E-Sec_Monograph_FINAL_11072003/$FILE/E-Sec_Monograph_FINAL_11072003.pdf

A couple other recent titles from the above web page:
Phishing in the Digital Streams: The Growing Threat of Cyber Social Engineering to the Financial Sector

Blended Electronic Security Threats: Code Red, Klez, Slammer, and Bugbear

Is Time Right For Micropayments

From: Lynn Wheeler
Date: 12/01/2003 06:22 PM
To: 'internet-payments' <internet-payments@xxxxxxxx>
Subject: Is Time Right For Micropayments

http://www.informationweek.com/story/showArticle.jhtml?articleID=16401131
The tiny Internet sales are being hyped again, but skeptics still abound.
By Brian Bergstein, AP Technology Writer

NEW YORK (AP) -- An idea that seemingly evaporated along with dot-com mania is back: that the Internet would realize its full grass-roots potential if Web surfers could pay small amounts for tidbits of online content.

Several companies are again betting they can mine gold from ferrying around such "micropayments." Even credit-card giant Visa USA is exploring the prospect.

Boosters believe people could sell countless new creations on the Internet--from essays to advice--if only mechanisms existed to facilitate small payments. For authors of popular content, all those pennies would add up.

.. snip ...

UBL proceeds for e-commerce

From: Lynn Wheeler
Date: 12/01/2003 06:17 PM
To: 'internet-payments' <internet-payments@xxxxxxxx>
Subject: UBL proceeds for e-commerce

http://www.infoworld.com/article/03/12/01/HNubl_1.html
Universal Business Language 1.0, which is intended as a common XML message format for e-commerce, is now available for public implementation testing in a beta format, according to an official of OASIS.

The UBL 1.0 Beta proposal has been approved as an OASIS Committee Draft by the OASIS Universal Business Language Technical Committee. A formal announcement is expected from OASIS this week, said Jon Bosak, chairman of the OASIS UBL Technical Committee. The beta proposal is intended to provide specifications needed to begin implementation testing of UBL in advance of OASIS recommending it as a standard.

.. snip ...

DOD prepares for credentialing pilot

Refed: **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 12/03/2003 02:55 AM
To: 'internet-payments' <internet-payments@xxxxxxxx>
Subject: DOD prepares for credentialing pilot

http://www.washingtontechnology.com/news/1_1/daily_news/22265-1.html
https://web.archive.org/web/20040120050628/http://www.gcn.com/vol1_no1/daily-updates/24319-1.html

There were a couple talks on this in a seesion at yesterday's e.gov conference.
http://www.e-gov.com/events/2003/hls/conference/plenary.asp

Some of the things said were very similar to comments I made at NISSC meeting five years ago (although at the time, some number of the audience and possibly other session presenters blanched at the time). See
https://www.garlic.com/~lynn/x959.html#aads
and scroll down to 21st National Information Systems Security Conference.

e.gov presentation pointed to
http://www.fegc.org/
for more details on DCIS/FiXs program

The initial phase is authentication. Somewhat similar to FSTC's FAST and some of the non-financial authentication demo's done at BAI four years ago as well as NACHA pilot. FAST reference:
https://web.archive.org/web/20020605055711/http://fstc.org/projects/fast/index.cfm

BAI reference::
https://www.garlic.com/~lynn/99.html#224

NACHA pilot references:
https://www.garlic.com/~lynn/x959.html#aadsnacha

Presentation at e.gov session mentioned that follow-on phases can have authorization as well as authentication and the DOD switch will not only be able to route requests between different back-end servers but also interface into NACHA.

ATM Fraud, Banking Your Money

From: Lynn Wheeler
Date: 12/06/2003 07:41 PM
To: 'internet-payments' <internet-payments@xxxxxxxx>
Subject: ATM Fraud, Banking Your Money

http://www.msnbc.com/news/998335.asp
ATM fraud: Banking on your money
NBC NEWS

Nov. 30 Chances are you did it this weekend: stopped off at the ATM for some cash. Quick and convenient, automatic teller machines are everywhere these days, malls, supermarkets, gas stations. And we trust that the transaction is as safe and secure as it would be at the bank. That’s what some criminals are banking on. A Dateline Hidden Camera Investigation shows a new kind of scam, with criminals setting up and operating their own ATM machines, hoping to steal your personal information and later, your cash. And it can happen with a single swipe of bank card. NBC’s Victoria Corderi reports.

... snip ...

The Digital Insider: Backdoor Trojans ... fyi

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Lynn Wheeler
Date: 12/11/2003 04:01 PM
To: 'internet-payments' <internet-payments@xxxxxxxx>
Subject: The Digital Insider: Backdoor Trojans ... fyi

The Digital Insider: Backdoor Trojans

new security paper that should be appearing shortly on the world bank e-security/e-finance web pages

e-security/e-finance main web page:
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/9f941053fd4293dc852569510022c5a0/77768cb67681ae7c85256d09005807df?OpenDocument

publications web page (where above reference should be appearing shortly)
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/SearchGeneral?openform
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/SearchGeneral?openform&E-Security/E-Finance&Publications
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/SearchGeneral?openform&E-Security/E-Finance&Publications

other papers from the above web page

Electronic Safety and Soundness: Securing Finance in a New Age Thomas Glaessner, Tom Kellermann, and Valerie McNevin (October 2003) This Monograph focuses on the sustainable development of e-finance and e-commerce. It raises awareness on the risks involved, as well as offers recommendations on how to mitigate these cyber-risks so that the shift to electronic financial services is conducted in a safe and sound manner. This paper and its technical annexes identify and discuss four key pillars that are necessary to foster a secure electronic environment and a sustainable global financial sector.

Phishing in the Digital Streams: The Growing Threat of Cyber Social Engineering to the Financial Sector Tom Kellermann, CISM and Yumi Nishiyama (October 2003) Phishing is a form of social engineering that is increasingly threatening the financial sector. Fake or spoofed bank websites, illegitimate emails, malicious code and other such deceptive methods are used to lure sensitive information (such as bank account information) away from users. Criminals then use this stolen information to conduct financial theft.

Blended Electronic Security Threats: Code Red, Klez, Slammer, and Bugbear Tom Kellermann and Yumi Nishiyama (June 2003) Blended threats (e.g. worms) exploit vulnerabilities in software code, allowing them to circumvent perimeter defenses like firewalls, intrustion detection systems, virus scanners and encryption. According to CERT 4,000 such vulnerabilities were found last year. This report depicts some of the most prolific worms of the information age.

Electronic Security: Risk Mitigation in Financial Transactions Thomas Glaessner, Tom Kellermann, and Valerie McNevin (June 2002) This is the new and improved version of this paper. A new Pillar 8 on layered security has been added as to have major improvements within the sections on Insurance, Regulatory and Supervision and Annex I. We took over five months of comments and criticisms from around the world to finalize this third version. It builds on a previous series of papers (see Claessens, Glaessner, and Klingebiel, 2001, 2002) that identified electronic security as a key component to the delivery of e-finance benefits. This paper and its technic al annexes identify and discuss seven key pillars necessary to the fostering of a secure electronic environment. Hence, it is intended for those formulating broad policies in the area of electronic security and those working with financial services providers (e.g., executives and management). The detailed annexes of this paper are especially relevant for chief information and security officers responsible for establishing layered security. First, the paper provides definitions of electronic finance and ele ctronic security and explains why these issues deserve attention. Next, it presents a picture of the burgeoning global electronic security industry. Then, it develops a risk-management framework for understanding the trade-offs and risks inherent in the electronic security infrastructure. It also provides examples of trade-offs that may arise with respect to technological innovation, privacy, quality of service, and security in the design of an electronic security policy framework. Finally, it outlines issues in seven interrelated areas that often need attention in the building of an adequate electronic security infrastructure. These are (i) the legal framework and enforcement; (ii) electronic security of payment systems; (iii) supervision and prevention challenges; (iv) the role of private insurance as an essential monitoring mechanism; (v) certification, standards, and the roles of the public and private sectors; (vi) improving the accuracy of information about electronic security incidents and creating better arrangements for sharing this information; and (vii) improving overall education about these issues as a key to enhancing prevention.

Mobile Risk Management: E-Finance in the Wireless Environment Tom Kellermann (May 2002) This paper documents the risks to electronic security via identity theft, hacking, etc. that wireless technologies may present in the context of delivery of financial services.

E-Finance in Emerging Markets: Is Leapfrogging Possible? Stijn Claessens, Thomas Glaessner, Daniela Klingebiel (June 2001) E-Finance can lead to much lower costs and greater competition in financial services. For countries with underdeveloped financial systems, e-finance offers an opportunity to leapfrog.

Electronic Finance : Reshaping the Financial Landscape Around the World Stijn Claessens, Thomas Glaessner, Daniela Klingebiel (July 2000) Financial Sector Discussion Paper No: 4 (July 2000) - The authors analyze the changes that have occurred in the financial products and services industry and their implications for public policies relating to areas such as safety and soundness and systemic considerations; competition policy; consumer protection and education; global public policy.

also key readings:
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/SearchGeneral?openform
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/SearchGeneral?openform&E-Security/E-Finance&Key+Readings
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/SearchGeneral?openform&E-Security/E-Finance&Key+Readings

URLs from above:

International Strategy for Cyberspace Security American Bar Association (ABA) (August 2003) By setting forth the categories of infrastructure to be protected, the key legal parameters and international initiatives, information on best resources and practices, guidance on the development of a complete security program, and implementation and technical considerations, this book in intended to to articulate an international strategy for cyberspace security.

Risk Management Principles for Electronic Banking The Basel Committee on Banking Supervision (July 2003) The Basel Committee on Banking Supervision identifies 14 risk management principles to improve upon the banking industry's electronic banking risk oversight policies and processes.

HIPAA Security Standards Department of Health and Human Services (February 2003) HIPAA (Health Insurance Portability and Accountability Act) security standards, to take effect 4/21/2005. Sections pertain to security of digital records.

The National Strategy to Secure Cyberspace U.S. Government (February 2003) The White House's national strategy to secure this critical infrastructure.

Common Sense Guide for Home Users Internet Security Alliance (February 2003) Explains why and how intruders break into home computers Outlines ways to prevent intruders from enter a home computer..

Additional Actions Needed to Better Prepare Critical Financial Market Participants U.S. General Accounting Office (February 2003) GAO study on effects of wide-scale disasters on the financial market. The GAO examined: 1) effects of 9/11 on facilities and telecom; 2) physical and information security plans; 3) regulatory efforts to improve both preparedness and market oversight to reduce risks

Critical Infrastructure Protection: Efforts of the Financial Services Sector to Address Cybert Threats U.S. General Accounting Office (GAO) (January 2003) "Since 1998, the federal government has taken steps to protect the nation's critical infrastructures, including developing partnerships between the public and private sectors. These cyber and physical public and private infrastructures, which include the financial services sector, are essential to national security, economic security, and/or public health and safety."

Technology Risk Management Guidelines for Financial Institutions Monetary Authority of Singapore (January 2003) The purpose of this document is to make financial institutions aware of the myriad dimensions of technology risks, and the actions they should take to improve information technology security and protect their information assets.

FFIEC's Information Systems IT Examination Handbook Federal Financial Institutions Examination Council (FFIEC) (December 2002) Examiners may use this booklet when evaluating the financial institution's risk management process, including the duties, obligations, and responsibilities of the service provider for information security and the oversight exercised by the financial insitution.
The National Security Agency's (NSA) Guide to Securing Microsoft Windows XP R. Bickel, M. Cook, J. Haney, M. Kerr (DISA), CT01 T. Parker (USN), H. Parkes (October 2002) A guide to educating consumers about Windows XP Professional recommended security settings.

example: secure computing kernel needed

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 12 Dec 2003 11:29:56 -0700
To: "John S. Denker" <jsd@xxxxxxxx>
Cc: cryptography@xxxxxxxx
Subject: Re: example: secure computing kernel needed

At 12:02 PM 12/10/2003 -0500, John S. Denker wrote:
Previous discussions of secure computing technology have been in some cases sidetracked and obscured by extraneous notions such as
-- Microsoft is involved, therefore it must be evil.
-- The purpose of secure computing is DRM, which is intrinsically evil ... computers must be able to copy anything anytime.

there have been other discussions about multics and the paper from a year ago about not having a lot of the current vulnerabilities ... some comment that security has to be designed in from the start. misc. past refs to multics study
https://www.garlic.com/~lynn/2002e.html#47 Multics_Security
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002m.html#8 Backdoor in AES ?
https://www.garlic.com/~lynn/2002m.html#10 Backdoor in AES ?
https://www.garlic.com/~lynn/2002m.html#58 The next big things that weren't
https://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
https://www.garlic.com/~lynn/2002p.html#6 unix permissions
https://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003i.html#59 grey-haired assembler programmers (Ritchie's C)
https://www.garlic.com/~lynn/2003j.html#4 A Dark Day
https://www.garlic.com/~lynn/2003k.html#3 Ping: Anne & Lynn Wheeler
https://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
https://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
https://www.garlic.com/~lynn/2003m.html#1 Password / access rights check
https://www.garlic.com/~lynn/2003o.html#5 perfomance vs. key size

there is also a number of discussions about the gnosis, keykos, eros lineage ... random refs to gnosis, keykos, &/or eros
https://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
https://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
https://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001n.html#10 TSS/360
https://www.garlic.com/~lynn/2002f.html#59 Blade architectures
https://www.garlic.com/~lynn/2002g.html#0 Blade architectures
https://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
https://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
https://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002j.html#75 30th b'day
https://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
https://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
https://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
https://www.garlic.com/~lynn/2003j.html#20 A Dark Day
https://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
https://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
https://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
https://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts
https://www.garlic.com/~lynn/2003m.html#24 Intel iAPX 432
https://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing?

there is some number of efforts being done taking advantage of itanium-2 hardware features (at least one such project in m'soft).

example: secure computing kernel needed

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: "Paul A.S. Ward" <pasward@xxxxxxxx>
Cc: "John S. Denker" <jsd@xxxxxxxx>, cryptography@xxxxxxxx
Subject: Re: example: secure computing kernel needed
Date: Sun, 14 Dec 2003 15:23:47 -0700

At 07:25 PM 12/11/2003 -0500, Paul A.S. Ward wrote:
I'm not sure why no one has considered the PC banking problem to be a justification for secure computing. Specifically, how does a user know their computer has not been tampered with when they wish to use it for banking access.

actually the EU FINREAD (financial reader) standard is quite directed at this area. basically a secure entry/display\token-interface device. part of the issue is not skimming any pin-entry that may be assumed as possible with just about all keyboard-based entry (aka tamper evident device .... supposedly somewhat consumer equivalent of the TSM ... trusted security module and tamper evident guidelines for point-of-sale terminals). In effect, finread is isolating some set of secure components into a tamper evident housing that has something akin to a trusted security module.

the other aspect somewhat shows up in the digital signature area. fundamentally a digital signature may be used for authenticating (and message integrity) ... but not, by itself as to "agreement" in the legal signature sense. the issue is how to create an environment/infrastructure for supporting both straight-forward authentication as well as intention/agreement

in theory finread has the ability to securely display the value of a transaction (and possibly other necessary details) and then requires a PIN entry after the display as evidence of

something you know authentication
being able to infer agreement with the transaction.

pretty much assumed is that finread implies some sort of token acceptor device ... which in turn implies a something you have token authentication.

so finread is attempting to both address two-factor authentication (and possibly three if biometric is also supported) as well as establish some environment related for inferring agreement/intention/etc as required per legal signature.

possibly overlooked in the base eu finread work is being able to prove that the transaction actually took place with a real finread device as opposed to some other kind of environment. In the (financial standard) X9A10 working group on the X9.59 financial standard for all electronic retail payments
https://www.garlic.com/~lynn/x959.html#x959
we spent some amount of time on not precluding that the signing environment could also sign the transaction i.e.

amount displayed on secure secure display,
pin/biometric securely entered (after display occurs)
token digitally signs (after pin/biometric entered)
finread terminal digital signs (after token signs)

the 2nd & 3rd items (alone) are two (or three) factor authentication. however, in conjunction with the first and fourth items some level of assurance that the person agrees with the transaction.

lots of past finread references:
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
https://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
https://www.garlic.com/~lynn/aadsm15.htm#40 FAQ: e-Signatures and Payments
https://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
https://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
https://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature

Difference between TCPA-Hardware and a smart card (was: example:secure computing kernel needed)

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: iang@xxxxxxxx
Cc: Stefan Lucks <lucks@xxxxxxxx>,
 Jerrold Leichter <jerrold.leichter@xxxxxxxx>,
"Paul A.S. Ward" <pasward@xxxxxxxx>, cryptography@xxxxxxxx
Subject: Re: Difference between TCPA-Hardware and a smart card (was:  example:secure computing kernel needed)
Date: Thu, 18 Dec 2003 20:03:51 -0700

At 09:38 AM 12/16/2003 -0500, Ian Grigg wrote:
In the late nineties, the smart card world worked out that each smart card was so expensive, it would only work if the issuer could do multiple apps on each card. That is, if they could share the cost with different uses (or users).

This resulted in a big shift to multi-application cards, and a lot of expensive reworking and a lot of hype. All the smart card people were rushing to present their own architecture; all the user banks were rushing to port their apps back into these environments, and scratching their heads to come up with App #2 (access control, loyalty...) .....

I've maintained since the mid-90s ... that the idea of multi-app smartcard is from sometimes in the '80s. the tarket was the portable computing environment .... before there was portable input & output technology. One of the reasons for smartcard standards was to have interoperability between input/output support stations .... and the portable computing.

The mid-90s saw some take-off in capability of multi-app smartcards because the technology that could be packaged into a smartcard got greater.

Also by the mid-90s, there was portable input & output technology and PDAs and cellphones were starting to rapidly fill the target market niche for multi-app smartcards (where everybody had their own portable computing input/output capability w/o having to find a station someplace).

One of the other target market niches for the portable computing devices was the offline environment (again left=over from the 80s) .... however, with the pervasive penetration of the Internet into the world market .... followed by all sorts of wireless capability .... any target offline market niche is rapidly going the way of the dinosaurs. One might claim that continuing momentum for multi-app smartcards is the enormous investment that was made starting by at least the late '80s continuing up through the current time.

So while there was an escalating amount of capability that could be packaged in a smartcard form-factor by the late 90s along with an escalating cost .... apparently requiring escalating feature/function to try and justify the escalating costs .... why would somebody want significant amount of capability in what is effectively a deaf & dumb device (w/o its support stations) .... when you could get enormously better usability by packaging the significant amount of capability in PDA/cellphone form factor.

i tried to take the opposite track with the aads chip strawman .... find a reasonably compelling business case for a hardware token .... and then totally focus on that function. the compelling business use selected was authentication. aads attempts to totally focus on KISS authentication as a compelling business reason for a hardware token .... with aggressive discarding everything that doesn't support the authentication compelling business use (if something non-KISS authentication is needed .... get a PDA or cellphone).

misc. aads stuff:
https://www.garlic.com/~lynn/x959.html#aads

Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Stefan Lucks <lucks@xxxxxxxx>
Cc: Jerrold Leichter <jerrold.leichter@xxxxxxxx>,
Ian Grigg <iang@xxxxxxxx>,
"Paul A.S. Ward" <pasward@xxxxxxxx>,
cryptography@xxxxxxxx
Subject: Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Date: Sat, 20 Dec 2003 07:37:12 -0700

At 10:51 AM 12/16/2003 +0100, Stefan Lucks wrote:
I agree with you: A good compromise between security and convenience is an issue, when you are changing between different smart cards. E.g., I could imagine using the smart card *once* when logging into my bank account, and then only needing it, perhaps, to authorise a money transfer.

This is a difficult user interface issue, but something we should be able to solve.

One problem of TCPA is the opposite user interface issue -- the user has lost control over what is going on. (And I believe that this originates much of the resistance against TCPA.)

In sci.crtypt, there has been a thread discussing does OTP (one-time-pad) and how does integrity and authentication play and somewhat subtread about does authentication of a message .... involve checking the integrity of the contents and/or checking the origin of message. A security taxonomy, PAIN:
• privacy (aka thinks like encryption)
• authentication (origin)
• integrity (contents)
• non-repudiation

https://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
https://www.garlic.com/~lynn/2003p.html#6 Does OTP need authentication?
https://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?

One of the issues is that privacy, authentication, and integrity are totally different business processes and that the same technology, lets say involving keys might be involved in all three, aka digital signatures (& public/private keys) can be used to simultaneously provide for authentication (of sender) and integrity (of message contents).

Both privacy (encryption) and authentication (say digital signatures) can involve keys that need protecting; privacy because key access needs to be controlled to prevent unauthorized access to data, authentication because unauthorized access to keys could lead to impersonation.

In the authentication case, involving public/private keys .... the business requirement has sometimes led to guidelines that the private key is absolutely protected and things like key escrow is not allowed because it could contributed to impersonation.

In the privacy csse, involving public/private keys ... the business requirement can lead to guidelines that require mandated escrow of private key(s) because of business continuity issues.

This can create ambiguity where the same technology can be used for both authentication and privacy, but because the business processes are different, there can be mandated requirement that the same keys are never used for both authentication and privacy ... and it is mandated that authentication keys are never escrowed and that privacy keys are always escrowed.

TCPA chip can also be used to protect private keys used in authentication .... either authentication of the hardware component as its own entity .... say like a router in a large network, or possibly implied authentication of a person that "owns" or possesses the hardware component.

An authentication taxonomy is 3-factor authentication:
• something you have
• something you know
• something you are

A hardware token (possibly in chipcard form factor) can be designed to generate a unique public/private key pair inside the token and that the private key never leaves the chip. Any digital signature that can be verified by the corresponding public key can be used to imply something you have authentication (i.e. the digital signature is assumed to have originated from a specific hardware token). A hardware token can also be designed to only operate in specific way when the correct PIN/password has been entered .... in which case the digital signature can imply two-factor authentication, both something you have and something you know.

From a business process standpoint it would be perfectly consistent to mandate that there is never key escrow for keys involved in authentication business process while at the same time mandating key escrow for keys involved in privacy.

At issue in business continuity are business requirements for things like no single point of failure, offsite storage of backups, etc. The threat model is 1) data in business files can be one of its most valuable assets, 2) it can't afford to have unauthorized access to the data, 3) it can't afford to loose access to data, 4) encryption is used to help prevent unauthorized access to the data, 5) if the encryption keys are protected by a TCPA chip, are the encryption keys recoverable if the TCPA chip fails?

Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Ernst Lippe <ernstl@xxxxxxxx.nl>
Cc: Jerrold Leichter <jerrold.leichter@xxxxxxxx>,
cryptography@xxxxxxxx
Subject: Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Date: Sat, 20 Dec 2003 14:39:47 -0700

On Fri, 2003-12-19 at 12:40, Ernst Lippe wrote:
It is not really true that there are so few smartcards. Almost every mobile phone contains one (the SIM module is a smartcard).

Also the situation in Europe is quite different from the USA. Electronic purses on smart cards are pretty common here, especially in France and the Netherlands, where most adults have at least one.

But it is true that there are only very few smart card enabled applications. I have worked on several projects for multifunctional use of these smart cards and almost all of them were complete failures.

one can claim that the SIM module isn't a smartcard as per the original design point .... it is a mobile phone that happens to leverage the smartcard manufacturing process.

my assertion is that the original smartcard design point was as a portable computing infrastructure that didn't have portable input/output technology. a huge investment went into standards (so that these cards could be carried around and still interoperate with various input/output stations) and volume manufacturing faclities. Just because they are the same physical components doesn't mean that they are the same business.

my observation has been that the stored-value smartcards were an economic trade-off .... supposedly because of either 1) extremely high telco fees and/or 2) availability problems with telco connectivity .... giving everybody smartcards and all merchants "offline" (aka smartcard) point-of-sale terminals ... was less expensive than an online paradigm.

in the US .... with ubiquitous and inexpensive telco availability ... it was less expensive to go with the standard online POS terminals and stored-value using the traditional magstripe interface (aka it was difficult to justify the increased chip expense based on any possible savings in telco &/or online transaction costs).

my contention in the AADS chip strawman scenario ...
https://www.garlic.com/~lynn/x959.html#aads

that with aggresive focus on compelling business use of hardware token (regardless of form factor) as an authentication device, it should be possible to justify the hardware token just based on fraud mitigation. with reasonable assumption about online connectivity becoming universal and inexpensive .... it is difficult to see any business justification for anything other than fraud mitigation. If the only business justification is authentication (for fraud mitigation), it isn't necessary to have multi-function features supported in the hardware token.

If there is no function/feature needed in a hardware token (other than authentication for an online environment), the provisioning for hardware tokens (regardless of form factor) is significantly simplified ... aka KISS.

The current provisioning convention for magstripe cards is there because the magstripe carries effectively shared-secrets for authentication ... which by simple security 101 rules says that there has to be a unique shared-secret per security domain (and every financial institution is their own security domain).

To some extent the provisioning of financial smartcards just continues to utilize the magstripe model. In addition, given offline transaction scenario and possible use of the card for non-authentication purposes, additional provisioning of the chip is required to load business rules so that its use is aligned with the financial institution issuing the card.

The assertion then is that in the scenario where the hardware token is purely an authentication device, most of the additional provisioning is eliminated (and becomes superfluous).

There is typically one additional argument used for institutional delivered hardware tokens (smartcards), even if there is no provisioning required ... which is that they tightly control the process so that the chip eventually delivered to the end-user can be assumed to meet some specified trust level.

So a person shows up at the doorstep with their own hardware token and wants to use it as their authentication device (whether it is a financial institution for electronic financial transactions, an employer for door badge access, or a gov. agency) .... the institution will frequently respond something about how can they trust the token?

So what might convince institutions to accept a consumer presented hardware token for authentication ... as opposed to mandating that the only hardware token that they will trust are the ones provided by the institution.

The PAIN mnemonic

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: "Carl Ellison" <cme@xxxxxxxx>
Cc: <cryptography@xxxxxxxx>
Subject: Re: The PAIN mnemonic
Date: Sun, 21 Dec 2003 07:41:35 -0700

At 11:20 PM 12/20/2003 -0800, Carl Ellison wrote:
Sorry, Lynn, but I don't buy this.

It's missing replay prevention (freshness)

and it included non-repudiation which is an unachievable, nonsense concept.

If you want to keep the mnemonic, you can change the 4th one to "non-replay".

- Carl

but non-replay would be pretty specific to transactions in flight .... there are probably gobs of additional threats .... if i was looking at data in flight and data at rest ... non-replay wouldn't even apply to all data in flight. non-repudiation could apply to data in flight (whether or not there was a replay attack) as well as data at rest. one possible issue is that you don't necessarily have to apply non-repudiation ... but it can be a significant security issue. One of the issues of asking that every entity have a unique password and nobody shares passwords could be considered a non-repudiation issue. In the case of insider fraud .... being able to tie every action to specific entity helps in post-event analysis of fraud (and possible conviction).

one could look at one aspect of non-repudiation as the requirement for everybody having a unique pin/password with guidelines never to share pin/passwords ... which could be considered across a broad range of security activities. replay might be considered a more specific kind of threat to just transactions. Some number of non-repudiation definitions allow for a lot more feature/function than simply don't share your password .... but a simple conjecture is that whoever originated "pain" might have been thinking of something as that simple.

in any case as mentioned in the previous reply .... doing search engine on
+security +pain +privacy +authentication +integrity +non-repudiation
on at least google and alta vista turns up several hundred references .... even discounting the medical entries where pain isn't an acronym/mnemonic

i just tried the same on google for
+security +pain +privacy +authentication +integrity +non-replay
and got zero hits

Non-repudiation (was RE: The PAIN mnemonic)

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: "Carl Ellison" <cme@xxxxxxxx>
Cc: <cryptography@xxxxxxxx>
Subject: Re: Non-repudiation (was RE: The PAIN mnemonic)
Date: Sun, 21 Dec 2003 09:45:54 -0700

At 08:23 AM 12/21/2003 -0800, Carl Ellison wrote:
That's an interesting definition, but you're describing a constraint on the behavior of a human being. This has nothing to do with cryptosystem choice or network protocol design. What mechanisms do you suggest for enforcing even the constraint you cite? Of course, that constraint isn't enough. In order to achieve non-repudiation, the way it is defined, you need to prove to a third party (the judge) that a particular human being knowingly caused a digital signature to be made. A signature can be made without the conscious action of the person to whom that key has been assigned in a number of ways, none of which includes negligence by that person.

Let's just leave the term non-repudiation to be used by people who don't understand security, but rather mouth things they've read in books that others claim are authoritative. There are lots of those books listing non-repudiation as a feature of public key cryptography, for example, and many listing it as an essential security characteristic. All of that is wrong, of course, but it's a test for the reader to see through it.

I mentioned PAIN as a (in-use) security taxonomy ... not a cryptosystem taxonomy or network protocol taxonomy ... and there is nothing precluding human factors in a security paradigm (like human factors issues of requiring unique shared-secret for every security domain leading to humans having to fumble around with scores of shared-secrets).

i agreee that non-repudiation has been seriously mis-used especially with regard to crypto systems. I've even made the assertion that possibly some of it can be attributed to having the word signature occur in both the term digital signature and legal signature .... even tho the two may have nothing at all to do with each other.

note, however, when I did reference PAIN as (one possible) security taxonomy .... i tended to skip over the term non-repudiation and primarily made references to privacy, authentication, and integrity.

sample of some past posts in various venues on the subject.
https://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
https://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign
https://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
https://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
https://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities

Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Seth David Schoen <schoen@xxxxxxxx>
Cc: Carl Ellison <cme@xxxxxxxx>,
'Stefan Lucks' <lucks@xxxxxxxx>,
cryptography@xxxxxxxx
Subject: Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Date: Mon, 22 Dec 2003 21:24:53 -0700

At 03:03 PM 12/21/2003 -0800, Seth David Schoen wrote:
Some people may have read things like this and mistakenly thought that this would not be an opt-in process. (There is some language about how the user's platform takes various actions and then "responds" to challenges, and perhaps people reasoned that it was responding autonomously, rather than under its user's direction.)

my analogy ... at least in online scenario has been to wild, wild west before there were traffic conventions, traffic signs, lane markers, traffic lights, standards for vehicles ... misc. traffic rules about operating an unsafe vehicle and driving recklessly, various minimums about traffic regulations, and things like insurance requirements to cover the cost of accidents. infected machines that do distributed DOS attacks ... might be considered analogous to large overloaded trucks w/o operational breaks (given rise to truck inspection and weighing stations). many ISPs are already monitoring, accounting and controlling various kinds of activity with respect to amount of traffic, simultaneous log-ins, etc. If there are sufficient online incidents ... then there could be very easy to declare machines that become infected and are used as part of various unacceptable behavior to have then declared unsafe vehicles and some sort of insurace be required to cover the costs of associated with unsafe and reckless driving on the internet. Direct costs to individuals may go up ... but the unsafe and reckless activities currently going on represent enormous infrastructure costs. Somewhat analogy to higher insurance premiums for less safe vehicles, government minimums for crash tests, bumper conventions, seat belts, air bags, etc.

part of the issue is that some number of the platforms never had original design point of significant interaction on a totally open and free internet (long ago and far away, vehicles that didn't have bumpers, crash tests, seat belts, air bags, safety glass, etc). Earlier in the original version of this thread ... I made reference to some number of systems from 30 or more years ago ... that were designed to handle such environments .... and had basic security designed in from the start ... were found to be not subject to majority of the things that are happening to lots of the current internet connected platforms.
https://www.garlic.com/~lynn/aadsm16.htm#8 example: secure computing kernel needed

misc. past analogies to unsafe and reckless driving on the internet:
https://www.garlic.com/~lynn/aadsm14.htm#14 blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
https://www.garlic.com/~lynn/aadsm14.htm#15 blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
https://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2002p.html#27 Secure you PC or get kicked off the net?
https://www.garlic.com/~lynn/2003i.html#17 Spam Bomb
https://www.garlic.com/~lynn/2003m.html#21 Drivers License required for surfing?

Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: "Ed Reed" <ereed@xxxxxxxx>
Cc: <iang@xxxxxxxx>, <cryptography@xxxxxxxx>
Subject: Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
Date: Tue, 23 Dec 2003 08:03:00 -0700

At 07:34 PM 12/22/2003 -0700, Ed Reed wrote:
Of course they do. Examples:

D&B and other credit reporting agencies. SEC for fair reporting of financial results. International Banking Letters of Credit when no shared root of trust exists. Errors and Ommissions Professional Liability insurance for consultants you don't know. Workman's Compensation insurance for independent contractors you don't know.

I don't think that trust checking was so much of the question .... a not uncommon scenario was

institution set up an account possibly that included checking with 3rd party trust agencies
did various kinds of online transactions where the actual transaction included account-only information
got an offer from a certification authority to move into the "modern world"
1. send the CA a copy of the institutions account database
2. the ca would convert the information in each account record into a certificate
3. each certificate would be digitally signed by the CA
4. the CA would returned each digitally signed transformed account record back to the institution and only charge a $100/certificate
the institution was to convert from modern online transactions to archaic offline transactions based on information in the certificate
the certificate would be a x.509 identity certificate that contain all of the account entity's identification information which would flow around attached to every transaction

fundamentally

x.509 identity certificates broadcast all over the world attached to every transaction were in serious violation of all sorts of privacy issues
certificates were fundamentally designed to address a trust issue in offline environments where a modicum of stale, static data was better than nothing
offline, certificate oriented stale, static processing was a major step backward compared to online, timely, dynamic processing.
the traditional outsourced trust has the relying-party contracted with the trust agency so that there is some form of legal obligation, the traditional 3rd-party CA model has no such legal obligation existing between the relying-party and the trust/certifying agency (the contract is frequently between the trust agency and the key owner, not the relying-party).

In the mid to late 90s ... some financial institutions attempted to salvage some of the paradigm (because of the severe privacy and liability issues) by going to relying-party-only certificates for online transactions. However, it is trivial to show that the stale, static information in the relying-party-only certificate was a trivial subset of the information that would be accessed in the real account record for the online transactions ... and therefor it was trivial to show that stale, static certificates were redundant and superfluous. misc. past posts regarding relying-party-only scenario:
https://www.garlic.com/~lynn/subpubkey.html#rpo

I think that the current federal gov PKI tries to address the legal obligation issue ... by creating a legal situation where essentially all the authorized CA operators are effectively agents of the federal PKI ... and all the relying parties have contracts with the federal PKI ... which simulates a legal obligation between the issuer of the certificate and the relying-parties.

In something like the D&B scenario ... the relying party contracts for some information with D&B about the entity that the relying party is interested in. In many of the traditional 3rd party CA-PKIs, there may be absolutely no legal relationship between the CA issuing the certificate (trust information) and any of the relying parties that are relying on the trust information i.e. the contract is between the CA issuing the certificate ... and the entity that the certificate is about. Since the entity (that the trust information is about) may be the party paying for the trust information ... they may have some motivation to shop around and get the most favorable report. Lets say I was applying for a loan and the loan institution needed a credit report. Rather than the loan institution contracting for the credit report, they rely on one supplied by the loan applicate. The loan applicant is free to choose from all the credit reporting agencies which credit report that they will buy for supplying to the loan institution.

random past threads on trust propagation:
https://www.garlic.com/~lynn/aadsm14.htm#42 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#45 Keyservers and Spam
https://www.garlic.com/~lynn/aadsm14.htm#46 An attack on paypal
https://www.garlic.com/~lynn/aadsm15.htm#26 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
https://www.garlic.com/~lynn/2001g.html#40 Self-Signed Certificate
https://www.garlic.com/~lynn/2003m.html#55 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#30 Is this right? Question about SSL and PKI

Non-repudiation (was RE: The PAIN mnemonic)

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: "Carl Ellison" <cme@xxxxxxxx>
Cc: <cryptography@xxxxxxxx>
Subject: Re: Non-repudiation (was RE: The PAIN mnemonic)
Date: Tue, 23 Dec 2003 10:48:16 -0700

humans
horses
mice

which doesn't mean that all mammal's have hooves, and correspondingly, all security doesn't have to have non-repudiation.

if the authorizations and/or permissions require for somebody to be an employee ... it is possible to authenticate somebody as being an employee w/o having to authenticate who they are ... just sufficient to authenticate them as whether or not they are allowed to do what they are allowed to do.

now, if you have 10,000 people that are authorized to do something ... and you have no tracking about what any specific person does .... then if some fraud takes place .... you may have no grounds whether to suspect any of the 10,000 over any of the others. However, if you have a policy that employees are strictly not suppose to share passwords and can get fired if they do .... and some fraud process takes placed ... done by an entity entering a specific password .... there would possibly be at least sufficient grounds to at least get a search warrant. The password by itself might not be sufficient to convict beyond a reasonable doubt ... but the audit trail might at least help point the investigation in the correct direction and also be admitted as circumstantial evidence. The defense attorneys in their opening statements said something about the prosecution showing means, motive, opportunity and misc. other things.

in any case, I would claim that both human and non-repudiation issues are part of security.

I wouldn't go so far as to say that just because a certification authority turned on a non-repudiation bit in a certificate .... and had no means at all of influencing human behavior, that just because the bit was turned on ... it, in anyway had anything to do with non-repducation.

there is recent thread in pkix mailing list about the name of the non-repudiation bit in a certificate being depreciated. There seems to be two separate issues ... 1) calling the bit non-repudiation isn't consistent with the meaning of the bit and 2) the semantics of what the bit supposedly controls.

Non-repudiation (was RE: The PAIN mnemonic)

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Amir Herzberg <amir@xxxxxxxx>
Cc: <cryptography@xxxxxxxx>
Subject: Re: Non-repudiation (was RE: The PAIN mnemonic)
Date: Tue, 23 Dec 2003 14:43:08 -0700

At 11:18 AM 12/23/2003 +0200, Amir Herzberg wrote:
Any alternative definition or concept to cover what protocol designers usually refer to as non-repudiation specifications? For example non-repudiation of origin, i.e. the ability of recipient to convince a third party that a message was sent (to him) by a particular sender (at certain time)?

there is some reference in old posting in pkix thread:
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation

possibly more than you want to know ... but merged security taxonomy and glossary ... sources at:
https://www.garlic.com/~lynn/index.html#glosnote

has definitions for:

non-repudiation
non-repudiation exchange
non-repudiation information
non-repudiation of creation
non-repudiation of delivery
non-repudiation of knowledge
non-repudiation of origin
non-repudiation of receipt
non-repudiation of sending
non-repudiation of submission
non-repudiation of transport
non-repudiation policy
non-repudiation service
non-repudiation token

plus:

NRD token
NRO token
NRS token
NRT token

Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Rich Salz <rsalz@xxxxxxxx>
Cc: cryptography@xxxxxxxx
Subject: Re: Ousourced Trust (was Re: Difference between TCPA-Hardware  and a smart card and something else before
Date: Tue, 23 Dec 2003 14:52:14 -0700

At 02:01 PM 12/23/2003 -0500, Rich Salz wrote:
If so, then I believe that we need a federated identity and management infrastructure. The difference is that the third-party PKI enrollment model still doesn't make sense, and organizations will take over their own identity issues, as with SAML and Liberty. Once you do that, adding "publicKey" as just another attribute is no big deal. With any luck, the new year will bring the analogy SOAP::other middleware as SAML::x.509 :)

the one detailed presentation that I've so far seen of a SAML based product .... looked like it had exactly the same message flows description that I sat thru in a Kerberos project audit in the '80s. I asked the guy making the presentation about the similarity to Kerberos message flows and he said something to the effect of: ah yes, kerberos.

random kerberos refs:
https://www.garlic.com/~lynn/subpubkey.html#kerberos

Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Rich Salz <rsalz@xxxxxxxx>
Cc: cryptography@xxxxxxxx
Subject: Re: Ousourced Trust (was Re: Difference between TCPA-Hardware  and a smart card and something else before
Date: Tue, 23 Dec 2003 20:23:07 -0700

At 02:01 PM 12/23/2003 -0500, Rich Salz wrote:
How many years have you been saying this, now? :) How do those modern online environments achieve end-to-end content integrity and privacy? My guess is that they don't; their use of private value-add networks made it unnecessary. If my guess is/was correct, than as more valuable transactions (or regulated data) flow over the commodity Internet, then those things will become important. Make sense? Am I right?

in days before the internet .... there was a lot more lo-tech attacks on financial transactions ... and when things like the credit card master file got harvested .... it was uaually pretty obviously an insider job. with the advent of the internet ... not only was it a open, insecure, commodity network .... but a lot of the attached systems were never designed to operate in effectively a hostile environment. because of a lot of contributing factors .... there was significant ambiguity when a merchant master file got harvested ... where the attack originated (insider or outsider). minor side thread regarding security proportional to risk with regard to attacks on the merchant master file:
https://www.garlic.com/~lynn/2001h.html#61

during the past ten years there have been some number of technologies for attempting to compensate for just the transport of the shared-secret account number in a transaction on an open, hostile network .... aka primarily ssl, minor reference with regard to emerging ssl and the original payment gateway:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

there has been a lot of threads about how much fraud SSL actually prevented .... since the major consumer retail financial related fraud ... non-internet, pre-internet, and internet has been bulk harvesting of repositories like a merchant master transaction file (for possibly the same effort to evesdrop packets in flight and extract a single account number .... it might be possible to harvest a merchant transaction file with tens of thousands of account numbers.

so the x9a10 working group was given the requirement for preserving the integrity of the financial infrastructure for all electronic retail transactions. To meet that, the x9.59 standard was defined which basically requires

end-to-end authenticated transactions between the consumer and the consumer's financial infrastructure and
that an account numbers used in authenticated transactions can't be used in non-authenticated transactions.

With strong, end-to-end authentication, it is possible to evesdrop a x9.59 transaction, extract the account number and still not be able to execute a fraudulent financial transaction. It is also possible to harvest x9.59 account numbers from merchant transaction files and still not be able to execute fraudulent financial transaction.

Hiding account numbers has been associated with identity theft, since in environment where the transactions aren't authenticated .... the account numbers have to be effectively treated as shared-secrets. The downside is that numerous business processes all along the processing chain require access and use of the account number. Just hiding the account number with SSL did little to address the major vulnerabilities and threats. In effect, the analysis shows that it is effectively impossible to provide necessarily protection for a shared-secret account number, no matter of how deep the earth was blanketed with cryptographic technology. The solution was to change the business process, require end-to-end strong authentication and eliminate the account number as a shared-secret (i.e. knowing the account number is not sufficient for performing a fraudulent transaction). misc. x9.59 standard refs:
https://www.garlic.com/~lynn/x959.html#x959

There was actually a couple other issues differentiating internet-based transactions and the VPN environment. The VPN environment was circuit based, it is possible to get service level agreements and utilized technology like modem loop-back diagnostics as part of a bootstrap problem determination procedure. Such an environment has a trouble desk and expects to finish first level problem determination in something like 5 minutes.

One of the last projects my wife and I had done before taking the early out (and doing some consulting for the payment gateway and ec-commerce stuff) was the HA/CMP product .... i.e. high availability/cluster multi-processing.
https://www.garlic.com/~lynn/subtopic.html#hacmp
there is a slight reference in one of the above aadsm5.htm archive posting to
https://www.garlic.com/~lynn/95.html#13
because some of the people in the above meeting had left and joined a client/server startup and were responsible for this thing called a commerce server .... who we then working with on this thing called a payment server for this thing that would be called e-commerce.

In any case, packet-based internet not only is commodity oriented from standpoint of security but also from the standpoint of availability, diagnostics, etc. It was possible to take an ISO8583 financial messages standards manual and repackage the same exact messages into internet packet protocol. However, it is extremely difficult to translate the standard VPN RAS (reliability, availability, serviceability) features into an internet environement. At some point in testing the payment gateway, there was a outage and a call to the trouble/call center. Three hours of manual investigation later, the trouble ticket was closed NTF (no trouble found). Trying to translate VPN-like RAS to an internet environment was much harder task than just about everything else combined (even just inventing problem diagnostic process for the call center).

In any case, there was an extremely large number of issues translating from a VPN environment to an internet environment .... way beyond simple issues like transaction evesdropping.

Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: pgut001@xxxxxxxx (Peter Gutmann)
Cc: ereed@xxxxxxxx,cryptography@xxxxxxxx,
        iang@xxxxxxxx
Subject: Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
Date: Thu, 25 Dec 2003 08:43:41 -0700

At 02:29 PM 12/25/2003 +1300, Peter Gutmann wrote:
X.509 certs were designed to solve the problem of authenticating users to the global X.500 directory. So they're good at what they were designed for (solving a problem that doesn't exist [0]), and bad at everything else (solving any other sort of problem).

disclaimer: I never actually worked on either X.500 or X.509 standards ... however, I do remember an acm sigmod meeting circa '90 where somebody did characterize x.500 as a bunch of networking engineers trying to re-invent 1960s database technology. minor past refs:
https://www.garlic.com/~lynn/2002g.html#24 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002g.html#28 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP

also, (not knowing about original intent of x.509) ... the PKI infrastructures I saw in the early to mid 90s ... had x.509 identity certificates that appeared to be populated with stale, static (and possibly subset) of information from a database entry .... targeted for use by relying parties in lieu of the relying parties actually being able to contact the real database (contained some piece of a x.500 directory entry that a relying-party could presumably use if they didn't have direct access to the x.500 directory).

the relying-party-only certificates of mid ot late 90s appeared to be much more of something that would authenticated an entity to a operational service .... having thrown out nearly all of the information that might be found in a database (especially anything that might possibly represent a privacy and/or liability issue). However, relying-party-only certificates could still be shown to be redundant and superfluous ... aka if i'm sending a digitally signed transaction containing an account number (or other database indexing value) to a relying party having the database .... then appending any kind of certificate that contains a small subset of the complete information from the database entry (including any public key or authentication material) is redundant and superfluous.

the IETF OCSP standards work seems to be all about a real-time protocol that a relying party can use to check with a (LDAP?) database about whether the information that might be in a specific certificate can still be relied on. It has some of the flavor of a distributed filesystem/database cache entry invalidation protocol. All of the CRL and OCSP stuff isn't about using the certificate for authenticating to an x.500 directory .... but whether the stale, static copy of information in the certificate is still good.

one of the PKI related efforts from the mid-90s specified adding a digital signature and a relying-party-only certificate to a iso8583 oriented financial transaction. It turns out that the typical iso8583 financial transaction eventually gets packaged as something like 60-80 bytes .... while the typically implemented relying-party-only certificate for this effort was between 4k bytes and 12k bytes. In this case, not only was the relying-party-only certificate redundant and superfluous but also represented a two orders of magnitude payload bloat.

Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: pgut001@xxxxxxxx (Peter Gutmann)
Cc: pgut001@xxxxxxxx, cryptography@xxxxxxxx,
ereed@xxxxxxxx, iang@xxxxxxxx
Subject: Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
Date: Sat, 27 Dec 2003 08:13:23 -0700

At 02:07 AM 12/28/2003 +1300, Peter Gutmann wrote:
That's my big gripe with OCSP, it's compromised in almost every way in order to make it completely bug-compatible with CRLs. It's really mostly an online CRL query protocol rather than any kind of status protocol (in other words a responder can give you an, uhh, "live" response from a week-old CRL via OCSP). A recent update to the protocol even removes the use of nonces, to make replay attacks possible.

in general, distributed cache/filesystem cache consistency algorithms aren't about trust or trust propagation but integrity and consistency.

I had done the initial distributed lock manager for ha/cmp. misc. past posts:
https://www.garlic.com/~lynn/2001.html#40 Disk drive behavior
https://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
https://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001j.html#47 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001k.html#5 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2002e.html#67 Blade architectures
https://www.garlic.com/~lynn/2002f.html#1 Blade architectures
https://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends
https://www.garlic.com/~lynn/2003i.html#70 A few Z990 Gee-Wiz stats

issue with certficates as cache entries ... is that they are purely r/o, static entries ... and the cache consistency protocols (either CRLs or OCSP) are purely with respect to whether the information is still fresh or not. however, I still contend that the primary design point for these deployed certificates is to allow relying-parties to perform offline operations when they wouldn't nominally have access to the real data (from which the certificate is derived).

the issue with the CRLs is that the are an electronic version of the paper booklets of invalid numbers in the credit card industry before online transactions. the issue is that the switch to a real online paradigm in the credit card industry in the '70s pretty much obsoleted the need for offline credentials (they retained the same form factor but added the magstripe for online transactions) and any infrastructure support for offline paradigm (like CRLs).

OCSP appears to acquire all the infrastructure costs of doing online transaction while retaining all the disadvantages of CRL paradigm ... i.e. undergo the costs of doing an actual online transaction w/o having any of the advantages of actually having done an online transaction. a trivial example is there is none of the benefits of aggregation (credit limit, fraud use patterns, etc) that comes with having a real online transaction.

the market niches for certificates are still

the offline world (which is rapidly disappearing) or
for extremely low value operations that don't justify the expense of online transaction.

The issues in the later are two-fold

online transaction related costs continue to rapidly decline and
for low/no value operations it is difficult to justify the cost and complexity of PKI infrastructure.

Non-repudiation (was RE: The PAIN mnemonic)

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Ed Gerck <egerck@xxxxxxxx>
Cc: cryptography@xxxxxxxx
Subject: Re: Non-repudiation (was RE: The PAIN mnemonic)
Date: Sun, 28 Dec 2003 14:24:55 -0700

At 01:34 AM 12/24/2003 -0800, Ed Gerck wrote:
However, IMO non-repudiation refers to a useful and essential cryptographic primitive. It does not mean the affirmation of a truth (which is authentication). It means the denial of a falsity -- such as:

(1) the ability to prevent the effective denial of an act (in other words, denying the act becomes a falsity); or

(2) the ability to prevent the denial of the origin or delivery of transactions.

so another way of looking at it ... is that somebody repudiates, refutes, and/or disavovs ... typically after the fact.

non-repudiation would be those things that would support countering claims of repudiation, refuting, and/or disavowing.

authentication is typically demonstrating that an entity is allowed to do something. authentication can include having a passphrase that is known by everybody in the organization. knowing the passphrase is sufficient to authenticate that somebody is allowed to do something. however, if somebody refutes that they had done something .... showing that they knew the passphrase (known by everybody in the organization) isn't sufficient to counter the repudiation claim.

an infrastructure that requires a unique passphrase for every person would help counter repudiation claims

public/private asymmetric cryptography systems where the infrastructure requires that a single person only has access to a particular private key would help counter repudiation claims. In that sense .... public/private key system can be seen as addressing both privacy and non-repudiation issues. the policies governing the dissemination of private keys in a asymmetric cryptography infrastructure can influence whether it just pertains to privacy and authentication and/or whether it can also be used to counter repudiation claims. while making sure that one & only one person has knowledge of a specific private key, in no way impacts the asymmetric cryptography operations ... the process can be used in countering repudiation claims.

while repudiation tends to be a human act .... it is entirely possible to have infrastructure and organizational implementation features that support countering claims of repudiation when they occur.

say dozens of people know (the same) vault combination lock (authentication) .... which doesn't do anything to counter a particular person's claim that they didn't enter the vault, however video surveillance and door badge access logs could be considered as part of security taxonomy for countering repudiation claims.

another example might be express package delivery signature

Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Rich Salz <rsalz@xxxxxxxx>
Cc: cryptography@xxxxxxxx
Subject: Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
Date: Mon, 29 Dec 2003 12:40:28 -0700

On Mon, 2003-12-29 at 10:16, Rich Salz wrote:
Not sure what the guy meant by that. But yes, SAML flows are "just like" Kerberos flows. And Liberty and WS-Federation look a lot like DCE cross-cell (er, Kerberos inter-realm) flows. After all, there's only not many ways to do secure online trusted third-party authentication.
/r$

talking to the guy after the presentation, i got the impression that they probably exactly copied the kerberos flows ... didn't even try to come up with something that turned out to be similar.

there were 30-40 people in the audience and I expected more people in the audience to have participated in discussion about kerberos vis-a-vis saml.

kerberos had come out of project athena that had been substantially jointly funded by two corporations ... project athena had a director from mit and two assistant directors, one from each of the funding corporations. one of them i had worked with for a long time when at science center at 545 tech sq. (random refs):
https://www.garlic.com/~lynn/subtopic.html#545tech

during the period we were doing hsdt & ha/cmp ... my wife and I also got to go by and do audits of progress of various project athena activities (including kerberos). One visit we had a lengthy overview and discussion of the recently (then) developed cross-domain protocol.

AADS Postings and Posting Index,
next, previous - home