Misc AADS & X9.59 Discussions

AADS Postings and Posting Index, next, previous - home


Separation of Roles - an example
RSA Adaptive Authentication
News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
History and definition of the term 'principal'?
PGP "master keys"
PGP "master keys"
PGP "master keys"
PGP "master keys"
PGP "master keys"
Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
Shifting the Burden - legal tactics from the contracts world
Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
FraudWatch - Chip&Pin, a new tenner (USD10)
FraudWatch - Chip&Pin, a new tenner (USD10)
Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
Petrol firm suspends chip-and-pin
Petrol firm suspends chip-and-pin
Reliable Connections Are Not
Payment systems - the explosion of 1995 is happening in 2006
Payment systems - the explosion of 1995 is happening in 2006
Reliable Connections Are Not
Petrol firm suspends chip-and-pin
Petrol firm suspends chip-and-pin
Chip-and-Pin terminals were replaced by "repairworkers"?
JIBC April 2006 - "Security Revisionism"
JIBC April 2006 - "Security Revisionism"
Petrol firm suspends chip-and-pin
JIBC April 2006 - "Security Revisionism"
Chip-and-Pin terminals were replaced by "repairworkers"?
Chip-and-Pin terminals were replaced by "repairworkers"?
Chip-and-Pin terminals were replaced by "repairworkers"?
3 of the big 4 - all doing payment systems
3 of the big 4 - all doing payment systems
3 of the big 4 - all doing payment systems
NSA knows who you've called
Tracking you, tracking me, tracking everyone
Markets in Imperfect Information - Lemons, Limes and Silver Bullets
3 of the big 4 - all doing payment systems
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
Spring is here - that means Pressed Flowers
ThreatWatch - markets in loss, Visa's take, 419 "chairmen"
Status of SRP
Status of opportunistic encryption
Status of opportunistic encryption
Status of opportunistic encryption
Status of SRP
Status of SRP
Status of opportunistic encryption
Status of opportunistic encryption
Status of SRP
Status of SRP
UK Detects Chip-And-PIN Security Flaw
UK Detects Chip-And-PIN Security Flaw


Separation of Roles - an example

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 16, 2006 12:32 PM
Subject: Separation of Roles - an example
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000699.html

basically, a lot of this is long term standard countermeasures to insider fraud. i have some recollection of early 80s starting to really get into threat analysis and countermeasures for insider exploits.

this somewhat all became obfuscated with the internet and the attention being paid to outsider exploits .... even thru the whole internet era, the studies have continued to show that the majority of fraud is still related to insiders. one might even conjecture the people behind serious fraud help promote the attention paid to outsiders as misdirection.

of course the other is that a lot of the internet stuff is somewhat more likely to make the popular press since the general public has more awareness of internet as opposed to the long standing backroom business processes where the majority of financial activity actually occurs.

as implied, there may be some issue with internet stuff more likely to involve people who have little or no knowledge and exerpience with real business issues and history of the serious threats, vulnerabilities, and exploits.

recent article:

Organization Seen Ignoring Main Culprit in Information Security breaches
http://www.sdcexec.com/article_arch.asp?article_id=8512

references to a few previous articles and/or studies
http://www.garlic.com/~lynn/aadsm12.htm#44 Identity Theft More Often an Inside Job
http://www.garlic.com/~lynn/aadsm17.htm#38 Study: ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders

of course, the above articles relate to (insider) breaches where the information may be turned around and used for identity and/or account theft. it doesn't talk about the other kinds of insider fraud like embezzlement or inflated purchase orders making payments to some relative.

so for some additional drift, a posting mentioning financial controls, payment protocols (and digital certificates)
http://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#36 X.509 and ssh

the above references the trival scenario of corporate checks that had logo stamped on them that they weren't good for more than a certain value. what they then found was that the work around was to write a whole collection of such checks (for just under the limit).

One of the times this came up was in the mid-90s involving some PKI proponents suggesting that digital certificates could have similar limit statements in support of using PKI-based (offline) financial transactions emulating the (offline) check model. At about the same time, there was an article in the national news about a NYC public school official writing (business checks with limit) 200 checks for $5000 each to funnel $1m to a front company as part of embezzelment.

The scenario that business had gone to was online transactions ... frequently implemented with a special business card (form of credit or debit card) that had backend business rules, not only about amount of individual purchases, but some implemented business rules about where the card could be used as well as what kind of purchases that the card could be used. It also had aggregated rules ... about max. money that could be spent per period (as countermeasure to embezzlement doing a large number of smaller individual transactions). Of course, there was also multi-party oversite of monthly activity (but it gained not requiring detailed multi-party oversite/approval of each individual purchase) ... which obviously didn't happen in this particular example.
https://www.financialcryptography.com/mt/archives/000699.html

What some of the PKI promponents had difficulty coming to grips with was that the stale, static offline check model was being replaced with dynamic, realtime, online operation.

The stale, static offline credential, certificate, diploma, license, letters of credit, letters of introduction paradigm had served the world for centuries providing "trusted" information to relying parties (who otherwise didn't have any other means of accessing and/or validating the information).

The PKI digital certificate is an electronic analog of that stale, static offline paradigm. Many of the PKI proponents seem to have trouble coming to grips with modern infrastructures moving to online, realtime operations and away from the old-fashion stale, static offline method (in part because online, realtime operation can close a lot of short-comings and vulnerabilities implicit with offline).

RSA Adaptive Authentication

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 18, 2006 11:42 AM
Subject: RSA Adaptive Authentication
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000700.html

when we were doing x9.59
http://www.garlic.com/~lynn/subpubkey.html#x959
http://www.garlic.com/~lynn/x959.html#x959

and aads
http://www.garlic.com/~lynn/x959.html#aads

starting in mid-90s, we called it parameterised risk management ... sort of extension of some of the transaction fraud scoring ... looking at individual transactions ... amount of the transaction, where the transaction originated, what kind of merchant the transaction was coming from, possibly what kind of purchases ... as well as sequence/aggregation of transactions, patterns, etc. ... types of stuff that you can do in a online paradigm system (can't do with an offlinestale, static, redundant and superfluous certificate paradigm).

this was then coupled with the overall integrity level of the token, and number of authentication factors involved (potentially requesting additional authentication factors for higher risk operations). furthermore given the kind of token to indicate the integrity level (as opposed to fixed integrity level recorded), the token integrity level could be updated in real time as circumstances changed and evolved (a token last month good for a million dollar transaction might only be good for a five hundred dollar transaction this month ... if some vulnerability in particular tokens had been discovered).

If it was a token that had to be used with terminals (POS terminal, ATM terminal) ... it could also take into account the integrity characteristics of the terminal (as well as changes to integrity of the terminal as technology advances over time) and various other physical location characteristics of the terminal that might increase or decrease occurance of risk/fraud.

a trivial example was somewhat the state-of-the-art with biometrics at the point. biometrics was fuzzy match and the infrastructure chose a fixed biometric scoring threshold ... above the threshold it would be accepted, below the threshold it would be rejected (this is somewhat the source of all the stuff in biometrics for false negatives and false positives). parameterised risk management just took the biometric scoring value and included it with the rest of the calculations. if a particular biometric scoring value was less than dynamic threshold necessary included with all the other calculations ... transaction might be rejected or another biometric value requested. the biometric state-of-the-art of the period would have totally different deployed infrastructure for low-value and high-value payments. parameterised risk management had the same online, realtime infrastructure and real-time parameterised risk management would dynamically adjust the requirements to meet the overall risks of a particular operation.

"dynamic authentication" is essentially just a small subset of parameterised risk management.
http://www.rsasecurity.com/node.asp?id=3018

the commonly used and well-known example of fraud scoring from the period was about a credit card being used for a $1 fuel purchase in LA (checking to see if lost/stolen card had been deactivated with no risk to the thief) followed within 20 minutes for the purchase of certain other kinds of goods.

course i've always claimed that parameterised risk management is just another application of Boyd for agile and adaptable operation.

misc. past posts mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
misc. references to Boyd from around the web
http://www.garlic.com/~lynn/subboyd.html#boyd2

the other comes out of the dynamic adaptive resource management (aka a kind of dynamic scoring of everything that went on) that I did as undergraduate in the 60s. It was picked up and included in products shipped at the time. In the mid-70s, some of it was dropped in mainframe operating system transition from 360s to 370s. However, I was allowed to re-introduce it within a couple years as the Resource Manager product ... 30th anniversary of the blue letter announcing the Resource Manager comes up on May 11th.

News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 22, 2006 10:54 AM
Subject: News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000691.html

so session authentication is vulnerable to trojans ... somewhat akin to man-in-the-middle attacks ... where the authentication porition is distinct from the operations to be performed.

the eu finread terminal
http://www.garlic.com/~lynn/subintegrity.html#finread

is somewhat countermeasure to that. each individual transaction is authenticated ... the finread terminal contains self-contained, independent keypad (for PIN something you know authentication), display (so the value of the transaction you are authenicating is the value you see), and reader (for the token something you have authentication). 3-factor authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor

every transaction requires newly displayed value on the finread value and re-entry of PIN in response.

the eu finread terminal standard calls for certified terminal ... which may benefit the person buying/owning the terminal. this is countermeasure to compromises of the environment where the authentication is taking place.

however, one of the things allowed for in the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

is that a token can digitally sign a transaction (as something you have authentication) and the environment that the authentication takes place in can also digitally sign the transaction. this is a countermeasure to "copy" &/or counterfeit terminals ... aka the finread standard calls for terminals to meet a certain anti-fraud specifications ... but doesn't mandate a mechanism for proving that a finread certified terminal was actually used for any particular operation (a counterfeit finread terminal may still trivially contain a trojan).

a digitally signing token (single factor something you have authentication) can be certified (to the satisfaction of relying parties) that it only operates when there has been additional authentication, aka the token requies correct PIN (something you know) before operation. The validation of a digital signature then can be taken as imply both something you have authentication as well as something you know authentication (i.e. two-factor authentication).

that normal PC end-point environments have been known to be trivially vulnerable to viruses and trojans for a long time. a certified eu finread terminal is countermeasure to such viruses and trojans by providing a separate secure environment where authentication takes place (as countermeasure to widespread viruses and trojans in the pc environment).

however, the eu finread terminal specification didn't mandate any provisions for proving that such a certified terminal was actually in use ... as a countermeasure to counterfeit terminals. x9.59 standard provided provisions for both digital signing by the authentication token as well as provisions for digital signing by the authentication environment.

one of the issues in previous comments (in other threads) about yes card attacks ... was that some authentication environment was compromised (either evesdropping in the physical area of the authentication or via compromised or counterfeit terminals). The result of the evesdropping was then used to create the counterfeit yes cards which were then used as far away as possible. This two-step process by the crooks was a countermeasure to rapid identification and elimination of the compromised authentication environment (and any associated compromised or counterfeit terminal). This maximized any non-trivial investment to compromise the authentication environment (and maximize the fraud return-on-investment).

another countermeasure has been privately owned PDA or cellphone devices for use in authenticated transactions (to unfamiliar terminals that may be compromised or counterfeit) ... assuming they have similar attack countermeasure properties as found in eu finread terminals. one of the more recent issues as that as PDAs and cellphones become more sophisticated, it seems to also be increasing their susceptibility to viruses and trojans.

misc. past posts related to yes cards
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 22, 2006 11:11 AM
Subject: News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000691.html

vis-a-vis security is harder than you think

long series of postings (dating back to ancient history) on the evils of buffer overflows and that common C language environments are especially vulnerable to coding mistakes that result in buffer overflows.
http://www.garlic.com/~lynn/subintegrity.html#overflow

and of course long series of postings regarding SSL (also dating back to ancient history) ... especially SSL digital certificates ... and frequently that they have more contributed more to the feeling of "comfort" (than any actual security)
http://www.garlic.com/~lynn/subpubkey.html#sslcert

News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 22, 2006 03:10 PM
Subject: News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
MailingList: Financial Cryptography
oh, for a little drift, some additional, recent comments regarding attacks on the "authentication environment" ... as opposed to attacks on the actual authentication ... and countermeasures.
http://www.garlic.com/~lynn/2006h.html#14 Security

History and definition of the term 'principal'?

Refed: **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: History and definition of the term 'principal'?
Date: Wed, 26 Apr 2006 14:31:23 -0600
To: cryptography@xxxxxxxx
Victor Duchovni wrote:
So with Kerberos the word has its narrower "named security entity" technical meaning. With X.509 one tends to talk of "subjects", "issuers", "registration authorities", "certification authorities", ... and the word "principal" is less common.

part of this has been that x.509 has layered certification authorities, digital certificates and other business processes on top of any direct interaction between parties. as a result, the focus of x.509 related descriptions tends to focus on the certification processes and the acceptance of those certification processes by relying parties (along with any digital certificate representation of those certification processes)

credentials, certificates, licenses, diplomas, letters of credit/introduction and other mechanisms have served the world for centuries ... providing information to relying parties, where the relying parties didn't have the information themselves and/or have other mechanisms for obtaining the information.

digital certificates has been electronic analog of those centuries old constructs for representation of information for use by relying parties (where the relying parties have no direct access to the information and/or other mechanisms for obtaining the information).

in my merged security taxonomy and glossary collected from a variety of resources
http://www.garlic.com/~lynn/index.html#glosnote

aka:

Security
Terms merged from: AFSEC, AJP, CC1, CC2, CC21 (CC site), CIAO, FCv1, FFIEC, FJC, FTC, IATF V3 (IATF site), IEEE610, ITSEC, Intel, JTC1/SC27 (SC27 site), KeyAll, MSC, NIST 800-30, 800-33, 800-37, 800-53, 800-61, 800-77, 800-83 FIPS140, NASA, NCSC/TG004, NIAP, NSA Intrusion, CNSSI 4009, online security study, RFC1983, RFC2504, RFC2647, RFC2828, TCSEC, TDI, TNI, vulnerability testing and misc. Updated 20060202 with terms from 800-77, 800-83


the only definition for principal comes from sc27:

principal
An entity whose identity can be authenticated. [SC27]


the merged taxonomy and glossaries from X9F (including some x.509 sources), i.e.

X9F
Terms merged from X9F document glossaries: WD15782, X509, X9.8, X9.24, X9.31, X9.42, X9.45, X9.49, X9.52, X9.62, X9.65, X9.69. Terms from ABA/ASC X9 TR1-1999 replace terms from X9F TG-16 glossary (identified by lower case x9 instead of upper-case X9). Original source documents include: X3.92, X3.106, x9.1, x9.5, x9.6, x9.8, x9.9, x9.17, x9.19, x9.23, x9.24, x9.26, x9.28, x9.30, x9.31, x9.41, x9.42, x9.44, x9.45, x9.49, x9.52, x9.55, x9.57, x9.62, x9.69 x9.74, x9.76, x9.78, x9.80, x9.82, and TG-17. (990710)


doesn't include a definition for principal.

PGP "master keys"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PGP "master keys"
Date: Fri, 28 Apr 2006 08:17:46 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Derek Atkins <warlord@xxxxxxxx>, cryptography@xxxxxxxx
Steven M. Bellovin wrote:
Ah -- corporate key escrow. An overt back door for Little Brother, rather than a covert one for Big Brother....

the key escrow meetings attempted to differentiate between keys used for authentication and keys used for securing corporate data (I only went to a couple of the meetings). the case of key escrow as part of securing corporate data was similar to business processes for backing up corporate data, disaster recovery, and no single point of failure. in fact, escrow of authentication keys was equally a violation of business standards as not having escrow of encryption keys.

there was cross-over from backup infrastructure and the transition from all corporate data residing in hardened datacenters to individual desktops ... where the they were finding critical corporate data being managed and maintained w/o adequate backup and recovery capabilities.

the point of key escrow as part of infrastructure securing corporate data ... was that the data belonged to the corporation ... and loss of keys could be equivalent to losing the data ... and as such, was as negligent as not backing up critical corporate data and not having a disaster/recovery plan.

there was some backup related study that claimed half of the corporations that had a disk failure (where the disk was not being backed up) containing critical corporate data ... filed for bankruptcy withing 30 days of the failure. i assumed that "critical" was stuff like account-billable files ... loosing a month worth of customer account billing information could create a real dent on the corporation's cash flow. one incident involved a corporation that lost something like $50m in monthly billings.

it wasn't suppose to be a back door to anything ... anymore than having copies of all corporate files on corporate backup tapes (however, the corporate backup tapes wouldn't be worth a lot if all the data has been secured with encryption ... and the encryption keys are lost).

PGP "master keys"

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PGP "master keys"
Date: Fri, 28 Apr 2006 09:42:51 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Derek Atkins <warlord@xxxxxxxx>,  cryptography@xxxxxxxx
re:
http://www.garlic.com/~lynn/aadsm23.htm#6 PGP "master keys"

note from the corporate side ... is was specifically the escrow of encryption keys for data at rest ... as part of prudent corporate asset protection; it was not escrow of authentication keys nor escrow of encryption keys used for communication.

the internal network was larger than the arpanet/internet from just about the beginning until possibly around summer of 85. at the time of the great change-over to internetworking protocol on 1/1/83, the number of arpanet/internet nodes was approx. 250 (a number that the internal network had passed in the mid-70s, the internal network passed 1000 nodes a little later in 83).
http://www.garlic.com/~lynn/subnetwork.html#internalnet

corporate inter-site links had to be encrypted ... which at the time met link encryptors .. there were claims that the internal network had over half of all the link encryptors in the world. there wasn't any corporate escrow issues with link encryptor keys. there were various problems with gov. agencies ... significant problems especially in europe getting gov/ptt authorization for corporate link encryptors (on corporate links, between corporate sites, purely carrying corporate data) especially when the links crossed country boundaries.

issues did start showing up in the mid-90s in the corporate world ... there were a large number of former gov. employees starting to show up in different corporate security-related positions (apparently after being turfed from the gov). their interests appeared to possibly reflect what they may have been doing prior to leaving the gov.

misc. past postings (mostly) referencing (internal) link encryptors
http://www.garlic.com/~lynn/99.html#210 AES cyphers leak information like sieves
http://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#0 The case against directories
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm18.htm#50 link-layer encryptors for Ethernet?
http://www.garlic.com/~lynn/aadsm18.htm#51 link-layer encryptors for Ethernet?
http://www.garlic.com/~lynn/2002b.html#56 Computer Naming Conventions
http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
http://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003i.html#62 Wireless security
http://www.garlic.com/~lynn/2004g.html#33 network history
http://www.garlic.com/~lynn/2004g.html#34 network history
http://www.garlic.com/~lynn/2004p.html#44 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004p.html#51 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004p.html#52 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
http://www.garlic.com/~lynn/2005c.html#38 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
http://www.garlic.com/~lynn/2005u.html#46 Channel Distances
http://www.garlic.com/~lynn/2005u.html#60 1970s data comms (UK)
http://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications
http://www.garlic.com/~lynn/2006e.html#37 The Pankian Metaphor

PGP "master keys"

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PGP "master keys"
Date: Fri, 28 Apr 2006 09:54:51 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Derek Atkins <warlord@xxxxxxxx>,  cryptography@xxxxxxxx
re:
http://www.garlic.com/~lynn/aadsm23.htm#6 PGP "master keys"
http://www.garlic.com/~lynn/aadsm23.htm#7 PGP "master keys"

and real-time reference from today ... on backup tapes ... at off-site location ... that weren't encrypted (and should have been):

Data storage firm apologizes for loss of railroad data tapes Information on as many as 17,000 workers at risk
http://www.boston.com/business/globe/articles/2006/04/28/data_storage_firm_apologizes_for_loss_of_railroad_data_tapes/

PGP "master keys"

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PGP "master keys"
Date: Sat, 29 Apr 2006 07:23:01 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Derek Atkins <warlord@xxxxxxxx>, cryptography@xxxxxxxx
Anne & Lynn Wheeler wrote:
issues did start showing up in the mid-90s in the corporate world ... there were a large number of former gov. employees starting to show up in different corporate security-related positions (apparently after being turfed from the gov). their interests appeared to possibly reflect what they may have been doing prior to leaving the gov.

re:
http://www.garlic.com/~lynn/aadsm23.htm#6 PGP "master keys"
http://www.garlic.com/~lynn/aadsm23.htm#7 PGP "master keys"
http://www.garlic.com/~lynn/aadsm23.htm#8 PGP "master keys"

one of the issues is that corporate/commercial world has had much more orientation towards prevention of wrong doing. govs. have tended to be much more preoccupied with evidence and prosecution of wrong doing. the influx of former gov. employees into the corporate world in the 2nd half of the 90s, tended to shift some of the attention from activities related to prevention to activities related to evidence and prosecution (including evesdropping).

for lots of drift ... one of the features of the work on x9.59 from the mid-90s
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

was its recognition that insiders had always been a major factor in the majority of financial fraud and security breaches. furthermore that with various financial functions overloaded for both authentication and normal day-to-day operations ... that there was no real practical way of eliminating all such security breaches with that type of information. ... part of this is my repeated comment on security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

the x9.59 approach was to eliminate the function overload so that the same information that was needed for normal day-to-day operation didn't also carry with it any authentication feature/attribute. the result was that data breaches could still occur, but no longer enabled the financial fraud that it once did ... and therefor it didn't really represent a serious security breach ... aka the countermeasure to financial fraud associated with the data breaches was to recognize that it was impossible to totally eliminate them, since the information was required extensively in day-to-day business processes, so to prevent the wrong doing, the authentication feature/attribute was removed from the associated information.

PGP "master keys"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PGP "master keys"
Date: Mon, 01 May 2006 11:56:18 -0600
To: leichter_jerrold@xxxxxxxx
CC: smb@xxxxxxxx, warlord@xxxxxxxx, cryptography@xxxxxxxx
leichter_jerrold@xxxxxxxx wrote:
A similar issue occurs in a civilian context, sometimes with fake employees, other times with fake bills. Often, these get found because they rely on the person committing the fraud being there every time a check arrives: It's the check sitting around with no one speaking for it that raises the alarm. The long-standing policy has been to *require* people in a position to handle those checks to take their vacation. (Of course, with direct deposit of salaries, the form of the fraud, and what one needs to do to detect it, have changed in detail - but probably not by much.)

multi-party operations were supposedly countermeasure to single person insider threats. the fraud response was collusion. so by at least the early 80s you started seeing work on collusion countermeasures. 25 years later, things have regressed to a pre-occupation with outsiders, intrusion threats and intrusion countermeasures; even tho insiders have continued to be the major source of fraud through the whole period. insiders may even leverage the pre-occupation with intrusion and outsiders to obfuscate the source of the exploit.

somewhat related issue with regard to sarbanes-oxley and auditing assumptions about independent information sources looking for inconsistencies.
http://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
http://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley

and a couple recent articles about current fraud pre-occupation
SSL Trojans: The next Great Bank Heist
http://www.infoworld.com/reports/18SRsslmalware.html
Ripped Off: Identity Theft - A View from the Financial Services Industry
http://www.mondaq.com/article.asp?article_id=39334&mostpopular=1


other posts in this thread:
http://www.garlic.com/~lynn/aadsm23.htm#6 PGP "master keys"
http://www.garlic.com/~lynn/aadsm23.htm#7 PGP "master keys"
http://www.garlic.com/~lynn/aadsm23.htm#8 PGP "master keys"
http://www.garlic.com/~lynn/aadsm23.htm#9 PGP "master keys"

Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 3, 2006 10:37 AM
Subject: Court rules email addresses are not signatures, and signs death warrant for Digital Signatures.
MailingList: Financial Cryptography
trsm.mckay on April 18, 2006 06:30 PM wrote:
Lynn: If you configure a system so that a token is required to perform a digital signature (e.g. contains the private key), and that a PIN is requested every time the token performs a digital signature (e.g. unlocks the token for a single transaction) - is that sufficient to judge the intent of the user to sign the email? At first glance I would think so, but there is an interesting philosophical line between specific intent and rote practice.

ref:
https://www.financialcryptography.com/mt/archives/000697.html
http://www.garlic.com/~lynn/subpubkey.html#signature

the issue isn't that the PIN is entered every time for the digital signature to imply human read, understood, agrees, approves, and/or authorizes ... the PIN has to be entered in response to a statement asking if the person agrees.

at POS terminal, the PIN entry and swiping the debit card is taken as two-factor authentication ... not human signature. the current pin-debit has the person entering the PIN and swiping the debit card on every transaction. from 3-factor authentication:
http://www.garlic.com/~lynn/subintegrity.html#3factor where the PIN entry represents something you know authentication and swiping the card represents something you have authentication (the current debit card PIN entry is equivalent to PIN entry with a digital signing hardware token and the current card swipe is equivalent to a hardware token doing a digital signature)

however, the part of the current POS terminal pin-debit transaction that represents read, understood, agrees, approves, and/or authorizes is NEITHER the PIN entry NOR card-swipe (the PIN entry and the card-swipe just represents two factor authentication).

the part of the current POS terminal pin-debit transaction that represents read, understood, agrees, approves, and/or authorizes (aka human intention or human signature) is when the terminal displays the transactions and asks the person to hit the yes/agree/enter button. Hitting that button is some explicit human operation that carries with it the sense of intent and having read, understood, agrees, approves, and/or authorizes.

In the current POS terminal pin-debit tranactions, neither the PIN entry NOR the card-swipe represents having read, understood, agrees, approves, and/or authorizes (i.e. doesn't represent human intention or human signature).

If the current POS terminal were to be redesigned for an X9.59 transaction
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

with a digital signing token that used a PIN ... and the terminal displayed the transactions and asked for the person to enter the PIN if they agreed ... then the entry of the PIN would be a demonstration of intent and having read, understood, agrees, approves, and/or authorizes.

If that PIN entry (in response to the message asking the person to enter the PIN as indication of agreement) and the digital signature was tied to the PIN entry ... then you have a chain of events that could imply having read, understood, agrees, approves, and/or authorizes (aka human intention and/or human signature).

The problem is with out that chain of events ... the PIN entry and digital signature is purely an indication of authentication and is not tied to any indication of having read, understood, agrees, approves and/or authorizes (or human intention and/or human signature)

It isn't that the digital signature can be demonstrated as part of PIN entry. The digital signature and the PIN entry by themselves are still simple pieces of multi-factor authentication and by themselves don't rise to the level of human intention or human signature.

It is some human action in response to something ... that rises to the level of human intention and having read, understood, agrees, approves, and/or authorizes. The "PIN entry" as a human action in response to a message asking for "PIN entry" as indication of agreement then rises to the having read, understood, agrees, approves, and/or authorizes (human intention, human signature).

previous posts in this thread:
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#48 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 3, 2006 11:37 AM
Subject: Court rules email addresses are not signatures, and signs death warrant for Digital Signatures.
MailingList: Financial Cryptography
aka, the PIN entry and the digital signature are purely multi-factor authentication.

re:
http://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/subpubkey.html#signature

however, if a certified environment can tie the digital signature to the PIN entry ... and the PIN entry to a human response/action asking for indication of agreement ... then that sequence of certified operations can be traced back to a specific human response asking for indication of agreement ... then you have a basis for tieing the existance of a digital signature back through a sequence of operations to some human response that can be taken as an indication of having read, understood, agrees, approves, and/or authorizes (i.e. human intent, human signature).

the digital signature as an indication of human intent ... has very little to do with the word signature appearing in the term digital signature and also in the term human signature. the "digital signature" is purely an indication of some operation. if a particular "digital signature" can be shown to be the final operation in a sequence of certified opeations that originated with some human response/action in response to something ... then you can use that sequence of certified operations as an indication of read, understood, agrees, approves, and/or authorizes (human intent, human signature).

this is one of the justifications for the x9a10 financial standards working group to have allowed for an x9.59 transaction to having a pair of digital signatures.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

the initial digital signature is supposedly from an entity's hardware token that is part authenticating that entity.

the second digital signature is by the digital signing environment ... say something like a certified finread terminal
http://www.garlic.com/~lynn/subintegrity.html#finread

the second digital signature is authenticating that a certified digital signing environment was used for the first digital signature ... and that certain certified operations occured as part of the generation of the first digital signature. again ... the digital signatures themselves are not indications of human intent or human signatures.

the first digital signature is to authenticate the human (not directly indicate human intent)

the second digital signature is to authenticate the digital signing environment ... and for specific certificate digital signing environments there may also be certified sequence of operations that are required to occur that then may be taken as an indication of a human having read, understood, agrees, approves, and/or authorizes (human intent, human signature).

it isn't the digital signatures themselves that indicate human intent.

the first digatal signature can be taken as authenticating a specific hardware token ... implying something you have authentication for a human. it is also possible that the speicific hardware token is certified to operate in a specific way (say the entry of the correct PIN or biometrics) as part of producing the digital signature. In that case, the first digital signature might be taken to imply both something you have authentication (the person has the token) and something you know authentication (the person has entered the correct PIN).

Then the second digital signature can be taken as authenticating a specific digital signing environment ... and that digial signing environment has a certified process that has a specific sequence of events. For a specific POS terminal environment, the certified sequence of events is that the terminal displays the transaction amount and asks the person to enter the (hardware token) PIN if they agree to the transaction.

It isn't the existance of either digital signature that directly establishes a human having read, understood, agrees, approves, and/or authorizes (human intent, human signature). It is that the digital signatures are taken as authenticating specific certified operations.

The first digital signature can be taken as implying two-factor authentication since there is a specific hardware token that is certified as having a unique private key and that the use of that private key to generate a digital signature is certified as requiring the correct PIN.

The second digital signature can be taken as implying a specific digital signing process because there is a specific POS terminal that is certified as having a unique private key and that the use of that private key to generate a digital signature is certified as only happening after a sequence of other events involving a hardware token and human actions.

This basically corresponds to the current direction of non-repudiation. The (stale, static) x.509 digital certificate non-repudiation bit has pretty much been totally depreciated. What is now being defined for non-repudiation are various kinds of "services" which are certified as executing a specific sequence of processes.

In that sense, the certified terminal operation discussed in this posting is a service that has a specific certified sequence of processes. furthermore, the terminal also digitally signs the operation as authenticating the service/processes associated with the hardware token digital signature.

again, there appears to have frequently been semantic confusion with the word signature appearing in both the term digital signature and the term human signature. the term "digital signature" is purely a manifestation or representation of a specific certified sequence of operations.

in order to understand what a "digital signature" might represent ... you then have to understand the exact sequence of operations that can be certified as occuring leading up to the generation of the "digital signature"

Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 3, 2006 03:20 PM
Subject: Court rules email addresses are not signatures, and signs death warrant for Digital Signatures.
MailingList: Financial Cryptography
so lets look at it from a slightly different perspecitve.

things end with the existance of a digital signature. the actual digital signature is representative of something you have authentication. it is the process of getting to the digital signature that correlates the creation of the digital signature with having read, understood, agrees, approves, and/or autherizes (human intent).

your suggestion was creating a certified process that can demonstrate that the generation of the digital signature was dependent on some human action (entering a PIN).

however, what was missing was being able to demonstrate any relationship between the human action entering of the PIN and having read, understood, agrees, approves, and/or autherizes (huamn intent).

so you need to show that
  1. the human response was a result of having read, understood, agrees, approves, and/or authorizes (human intent)
  2. the entering of the PIN was a specific a human response
  3. the generation of the digital signature was the result of entering the PIN
  4. the existance of the digital signature was the result of the generation of the digital signature.
the previous postings describe a second digital signature by a digital signing environment ... that digital signing environment is certified as requiring steps 1-4 as part of having the existence of a specific digital signature in conjunction with some specific item that has been digitally signed.

ref:
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#48 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#12 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

the other way of looking at it is from a trust path analysis for assurance and integrity. imagine the existance of a digital signature is the trunk of a tree. there are possibly millions of root endings that can lead to having the existance of a digital signature as a result. I choose the root endings that specifically start with human intent and then demonstrate a trusted path from the start at human intent (at some set of root endings) until I arrive at the existance of a digital signature (at the turnk)

then i work the process from the reverse direction ... can I start with the existance of a specific digital signature and have proof that it only traces back to starting with human intent ... or is it possible I could have arrived at the existance of a specific digital signature by starting someplace that doesn't involve human intent at all.

this is somewhat how i came up with the dual-use vulnerability of using digital signatures for both plain authentication as well as demonstration of human intent (i.e. read, understood, agrees, approves, and/or authorizes). I show that you can establish a trusted path from human intent to digital signature existance.

I then show that common digital signature authentication mechanisms will pass some random data to the client for digital signing (as countermeasure to replay attack on authentication). The client signs the random data w/o looking at it. I now can demonstrate getting to the existance of a digital signature that didn't originate with human intent.

I can also start with some other set of root endings that has a unique private key in a specific hardware token and that hardware token is given to a specific individual. I then show a direct path to the same "digital signature" at the trunk.

Starting with the something you have authentication root ending, you arrive at the existance of the digital signature representing something you have authentication. I may also be able to get to the same digital signature from starting with human intent and show a directly connected, certified, trusted, sequence of operations also results in the existance of the same digital signature. However, w/o one the one set of sequence of events, it is impossible to assume something you have authentication. W/o the other sequence of events, it is not reasonable to assume human intent

So the dual-use attack is can any server pass some valid transaction or contract in the guise of random data and have it signed w/o human intent being involved.

So there has been a couple of different suggestions as countermeasure to digital signature dual-use vulnerability. One is that you can proove that for every instance where you have applied a digital signature that didn't involve human intent, you appended a disclamer to the random data first, stating this particular digital signature was to not imply human intent. One problem is prooving a negative is difficult (showing that you have never generated a digital signature w/o first including the disclamer).

The other approach is having the digital signing environment also digitally sign the operation. The first digital signature by some something you have authentication is some certified mode of operation (that can be trusted by relying parties). The second digital signature attests to the certified sequence of operations that results in the existance of the first digital signature. This is sort of the certified EU finread terminal with the additional that the terminal also has to sign the same operation.

As I've commented before, some of this is possibly semantic confusion where the word signature occurs in totally different terms: digital signature and human signature.

The other scenario may be akin to the comfort that many people get from digital certificates.

For centuries, credentials, certificates, diplomas, licenses, letters of credit, letters of introduction, etc ... have been used to represent some information and/or processes.

Digital certificates are the electronic equivalent to this physical objects that have existed for centuries (as representation of something). My long tirade is that with online connectivity it is no longer necessary to settle for digital signatures as a substitute representing something ... you can have direct, real-time access to the real thing.

A digital signature on something is also a representation of something. However, a digital signature represents something you have authentication ... it doesn't represent human intent (as in read, understood, agrees, approves, and/or authorizes). This confusion is somewhat similar to peoples' mistaken perception that the existance of the non-repudiation bit in digital certificate as representing non-repudiation (just because some set of words are used in naming something ... doesn't automatically convey any attributes normally associated with the individual words ... to the named thing).

some past posts mentioning digital signature dual-use vulnerability:
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
http://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#28 solving the wrong problem
http://www.garlic.com/~lynn/aadsm21.htm#10 Clearing sensitive in-memory data in perl
http://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#6 long-term GPG signing key
http://www.garlic.com/~lynn/aadsm22.htm#7 long-term GPG signing key
http://www.garlic.com/~lynn/aadsm22.htm#48 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
http://www.garlic.com/~lynn/2005o.html#9 Need a HOW TO create a client certificate for partner access
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance

Shifting the Burden - legal tactics from the contracts world

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 4, 2006 03:22 PM
Subject: Shifting the Burden - legal tactics from the contracts world
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000710.html
http://unenumerated.blogspot.com/2006/05/security-and-burden-of-lawsuit.html

this is sort of my repeated description that the explicit contract is between the certification authority and the party that is having the certificate certified (and pays for the certificate).

this has represented an enormous problem all along for the trusted 3rd party certification authority operations. the foreys during the 90s to address the problem included trying to get legislation passed mandating digital certificates from "approved" certification authorities (codifying the relationship as rule of law ... outside of the business contract infrastructure).

the federal PKI program took another approach. GSA as representing the federal government relying party ... signed contracts with each of the approved certification authorities ... effectively making the approved certification authorities a kind of agent of the GSA (federal governemnt relying party) ... and therefor the certificates became a form of relying-party certificates (i.e. a legal fabrication that the entity issuing the digital certificates was the same as the entity relying on the certificates). misc. past posts about relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

this got around the problem of missing any sort of contractual relationship between the certificate issuing certification authorities and the relying party.

There was another effort in the mid-90s which touches both on changing the burden of proof as well as intent.

Some early digital certificate standard effort got really confused and defined a non-repudiation bit. This was taken to imply that if a relying party could produce a (any) digital certificate for a specific public key that could be used to validate a specific digital signature ... then whatever that digital signature had been applied to ... could be construed as a human intent (i.e. read, understood, agrees, approves, and/or authorizes).

The scenario was that there was resistance in the merchant population to spend the money installing the facilities to support digital certificate (PKI) based financial transactions. The non-repudiation proposal was that if a merchant could produce a (any) digital certificate (for a consumer's public key) containing the non-repudiation bit then in any disputes involving a related digitally signed financial transaction, the burden of proof would be reversed (i.e. burden of proof shifted from the merchant to the consumer).

So this represented some huge issues.

It eventually came to be generaly realized that having a non-repudiation bit in a digital certificate carried no meaning ... and the bit definition has since come to be depreciated.

The standard PKI protocols call for appending digital certificates to digitally signed operations ... but provide for no assurance mechanism that can prove what digital certificate a consumer actually appended to any specific transaction.

There would be no incentive for a consumer to actually append a non-repudiation bit carrying digital certificate to anything (especially when doing so shifted legal liability to them from the other party). On the other hand, there would be lot of incentive for a merchant to discover and be able to produce some consumer digital certificate with the non-repudiation bit set (even possibly if it wasn't originally appended).

Part of the confusion goes back to attempts to equate digital signatures to human signatures (as evidence the definition of a non-repudiation bit in digital certificate specification). Some of this could be considered semantic confusion with the word signature appearing in both the terms digital signature and human signature.

If you trace back all the steps that a "digital signature" can represent, it basically comes down to something you have authentication. There is nothing in any of the operations specified for dealing with a "digital signature" that can tie a existance of a "digital signature" to human intent (some human operation tied to read, understood, agrees, approves, and/or authorizes).

a couple recent posts on the subject:
http://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signature
http://www.garlic.com/~lynn/aadsm23.htm#12 Court rules email addresses are not signature
http://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signature

I expect that attempting to relate digital signature to human signatures and human intent (having read, understood, agrees, approves, and/or authorizes) will eventually go through some similar evoluation that happened to the non-repudiation concept. Rather than the existance of a static bit created at some point in the distant past, the most current non-repudiation thinking involves a whole bunch of (non-repudiation) services that *certify* specific sequence events occured as part of some operation (and it was these sequence of events as part of each operation that were necessary for creating the basis of any sort of non-repudiation).

A similar evoluation in the concept of human intent will be services that can certify that specific sequence of events occured as part of doing an operation (say digitally signing a transaction) that are the basis for establishing human intent (read, understood, agrees, approves, and/or authorizes). It isn't the existance of the digital signature that represents any sort of human intent (i.e. the actual digital signature just represents something you have authentication). It is the certifying of these other events, performed in conjunction with the digital signature, that is necessary for establishing the basis of any sort of human intent ... and therefor can be treated as human signature (read, understood, agrees, approves, and/or authorizes).

misc. past posts mentioning having worked on some of the word smithing of the cal. state electronic signature legislation and later the federal electronic signature legislation.
http://www.garlic.com/~lynn/subpubkey.html#signature

Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 5, 2006 03:52 PM
Subject: Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000709.html
E-commerce in crisis: When SSL isn't safe
http://www.infoworld.com/article/06/05/01/77515_18FEsslmalwareworks_1.html?s=feature

the PC end-point vulnerability has been long recognized ... that is part of the early motivation for the EU FINREAD terminal standard.
http://www.garlic.com/~lynn/subintegrity.html#finread

FINREAD moved authentication out of vulnerable PCs into a trusted authentication environment as well as providing mechanism for supporting transaction-based authentication (each transaction/operation is explicitly authentication) as opposed to just simple session authentication (with possibly encryption wrapper for security).

The recent discussion is that if you have a separate trusted authentication environment for authentication (based on digital signature authentication) then there are some additional benefit to relying parties to also have the trusted authentication environment also digitally signing the operation (so the relying party has some proof that a trusted authentication environment was in use as opposed to some compromised/counterfeit authentication environment).
http://www.garlic.com/~lynn/aadsm23.htm#12 Court rules email addresses are not signatures
http://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures

with respect about to earlier comment about having a token that requires a digital signing hardware token to have correct (human) PIN entry .... would allow a relying party to be able to associate a specific digital signature with some human operation (PIN entry), if the relying party had some way of knowing that the hardware token being used, in facted, required PIN entry.

Issues addressed by the EU finread terminal standard was to eliminate PC virus/trojan from logging the PIN value and then replaying the PIN values to the hardware token (w/o the users knowledge). The EU finread terminal standard provided from a countermeasure to the PC virus/trojan replaying PIN entries. However, the EU finread terminal standard didn't actually require the terminal to also digitally sign the transaction (providing an indication to the relying party that an finread terminal was actually being used ... as opposed to some counterfeit environment). For financial transaction, the finread terminal extracted the important parts of the data to be signed and displayed it along with the request for PIN-entry (as countermeasure to virus/trojan displaying a value different that what is in the actuall transaction)

There is an issue with the relying party knowing the operational characteristics of the hardware token being used for a digital signature (w/o which the relying party has no mechanism to know whether PIN-entry was even required ... or even if a hardware token is being used). The relying party having knowledge of the hardware token operational characteristics allows for some evaluation of whether it was actual simple one-factor authentication (something you have) ... or if possibly additional authentication factors were involved (multi-factor authentication).

There is also an issue with the relying party having knowledge of the operational characteristics of any kind of terminal (or other digital signing environment) that also digitally signs the operation. This provides the relying party with basis for doing further trust evaluation (like whether there was possibility that virus/trojan entered the PIN).

Finally with respect to comment about associating PIN-entry with indication of any human intent (read, understood, approves, agrees, and/or authorizes)
http://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signatures

The relying party having knowledge of the hardware token may have some basis for assuming that the digital signature implies that (the correct) PIN was entered. Having the 2nd digital signature from the terminal provides some basis for assuming that the PIN entry actually involved human interaction. That ties the token's digital signature to some human interaction. However, there is still no tie between the human interaction and read, understood, approves, aggrees, and/or authorizes.

However, if the relying party has knowledge of the terminal environment (that also digitally signs the operation), then there may be some basis for assuming that the terminal had displayed a message requesting the person to enter their PIN if they agreed with the operation (and critical pieces of the transaction is also displayed), and that the PIN was entered after the message was displayed. There is now some basis for the relying party to assume that the human interaction (PIN entry) was in response asking if the person agreed.

Early in the AADS chip strawman
http://www.garlic.com/~lynn/x959.html#aads

and X9.59 work,
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

we realized that transactions needed to be directly signed, that it should be possible for the digital signing (terminal) environment to also sign the transactions, and that the relying party needed to have access to both the token operational characteristics as well as any terminal environment operation characteristics (in order to correctly interpret and evaluate any meaning attached to the digital signatures ... as well as dynamic adaptive risk assesement).

this was one of the issues over the years involving the yes card technology ... the token is authenticated separately from the transaction operations ... opening various kinds of mitm-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm
or various kinds of other end-point vulnerabilities. some recent postings on yes card technology
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views
http://www.garlic.com/~lynn/aadsm22.htm#41 FraudWatch Chip&PIN

and is the issue in the SSL-evading trojans:
http://www.infoworld.com/article/06/05/01/77515_18FEsslmalwareworks_1.html?s=feature

again, another example where the end-point is authenticated separately from the actual operations ... creating additional cracks and vulnerabilities that may be exploited (MITM-attacks and/or interception and modification).

of course, in the AADS model ... the relying party could obtain online access to all of this information for correctly interpreting digital signatures ... in a digital certificate-less paradigm
http://www.garlic.com/~lynn/subpubkey.html#certless

we also talked to some of the people behind the X.509V3 digital certificate work and pointed out that such useful integrity information might be significantly more interesting to a relying party than anything that might be found in a CPS statement.

FraudWatch - Chip&Pin, a new tenner (USD10)

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 9, 2006 10:57 AM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
Petrol giant Shell has suspended chip-and-pin payments in 600 UK petrol stations after more than £1m was siphoned out of customers' accounts.
http://news.bbc.co.uk/2/hi/uk_news/england/4980190.stm


re:
https://www.financialcryptography.com/mt/archives/000673.html

previous post in this thread:
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin

misc. collected fraud, vulnerabilities, threats, exploit posts
http://www.garlic.com/~lynn/subintegrity.html#fraud

FraudWatch - Chip&Pin, a new tenner (USD10)

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 9, 2006 10:57 AM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000673.html
http://www.garlic.com/~lynn/aadsm23.htm#16 FraudWatch - Chip&Pin

and some late breaking:

Eight held over chip and pin fraud
http://www.guardian.co.uk/uklatest/story/0,,-5803656,00.html
Eight held over chip and pin fraud
http://www.thisislondon.co.uk/news/articles/PA_NEWA19204681146904793A00?source=PA%20Feed
Eight held over chip and pin fraud
http://www.24dash.com/content/news/viewNews.php?navID=34&newsID=5478


the above implies that the chip passes an image of magstripe information as part of the communication ... and that this information is being skimmed (possibly the magstipe image is included in some form of digital certificate and/or the chip terminal is designed in such a way that it simultaneously establishes chip communication and reads the magstripe?).

the skimmed information (from the chip?) is then used to counterfeit a magstripe card ... which is then used for fraudulent (magstripe) transactions (replay attack of static data)

it mentions that the PIN is also being skimmed which is then available for fraudulent (magstripe) pin-debit transactions. the implication then is that the chip's PIN is the same as the magstripe debit PIN (replay attack of static data)

Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 6, 2006 10:48 AM
Subject: Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000709.html
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera

Trusted Web Sites Not Always Trustworthy, Says Noted Computer Security Researcher
http://biz.yahoo.com/prnews/060505/sff027.html?.v=48

with respect to today's news articles on chip&pin fraud
http://www.garlic.com/~lynn/aadsm23.htm#16
http://www.garlic.com/~lynn/aadsm23.htm#17

a post in the original thread
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin

about chip&pin not being usable on the Internet because of vulnerabilities ... possibly similar skimming related vulnerabilities (for replay attacks).

Note that some of the vulnerabilities mentioned in this thread are similar to those faced when deploying corporate vpn for access by traveling and at-home employees.

some of this first showed up when employees would attach dial-up modems to their PCs and work and dial the internet. these PCs (when also connected to the internal corporate intra-net) allowed attackers to bridge attacks thru the dial-up connection, bypassing the corporate firewalls.

later with off-site VPN connections, the remote employee PCs required an internet connection in order to tunnel the VPN connection into the corporate network. Lots of the personal PC VPN implementations added all sorts of countermeasures attempting to keep attackers from using the PC to bridge into the corporate network (bypassing corporate firewalls).

a lot of these corporate VPN-related countermeasures (attempting to prevent attackers from using employee's PC internet connection to bridge into the corporate network) ... have been specifically directed at virus/trojan related vulnerabilities.

Petrol firm suspends chip-and-pin

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 6, 2006 11:46 AM
Subject: Petrol firm suspends chip-and-pin
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000713.html

some of the details are obscured. it seems that information is being skimmed in a chip&pin transactions to create a counterfeit magstripe cards. possibly both magstripe credit transactions and apparently also magstripe pin-debit transactions (using the pin entered during chip&pin transactions).

what isn't clear is whether the skimming of the magstripe information comes from physically reading the magstripe on a chip&pin card (during a chip&pin transaction) or if there is an image of the magstripe transmitted during the chip&pin transactions (which can be evesdropped). Basically using static data based authentication for replay attacks.

as mentioned in the earlier posts ... there have already been comments about not using chip&pin for internet transactions because of (some) vulnerabilities. internet vulnerabilities tend to either be various kinds of phishing, skimming, harvesting, evesdropping (for replay attacks):
http://www.garlic.com/~lynn/subintegrity.html#harvest

or mitm-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

recent posts
http://www.garlic.com/~lynn/aadsm23.htm#16
http://www.garlic.com/~lynn/aadsm23.htm#17
http://www.garlic.com/~lynn/aadsm23.htm#18

as previously noted, the financial standards x9a10 working group in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... this was all as to type of payment (credit, debit, stored-value, e-check, ALL) as well as environment (point-of-sale, face-to-face, non-face-to-face, internet, ALL)
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

Petrol firm suspends chip-and-pin

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@garlic.com>
Date: May 7, 2006 09:26 AM
Subject: Petrol firm suspends chip-and-pin
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000713.html

CHIP AND PIN CARDS IN CHAOS
http://www.tmcnet.com/usubmit/-chip-p-cards-chaos-/2006/05/07/1639879.htm

from above:
Association's spokeswoman Sandra Quinn said: They have used an old-style skimming device. They are skimming the card and copying the magnetic details.

... snip ...

Eight arrests in GLB1m fraud
http://scotlandonsunday.scotsman.com/index.cfm?id=684712006

from above:
Spokeswoman Sandra Quinn said: They are skimming the card, copying the magnetic details - there is no new fraud here.

... snip ...

Petrol firm suspends chip-and-pin
http://news.bbc.co.uk/1/hi/england/4980190.stm

however, from above:
A Shell spokeswoman said: Shell's chip-and-pin solution is fully accredited and complies with all relevant industry standards.

Chip and pin machine Chip and pin cards are designed to prevent fraud

We have temporarily suspended chip-and-pin availability in our UK company-owned service stations.

This is a precautionary measure to protect the security of our customers' transactions.

You can still pay for your fuel, goods or services with your card by swipe and signature.


... snip ...

??? so if it is ok to swipe your magstripe ... where is the information being skimmed (for production of a counterfeit magstripe card) ... is it possible an copy of the magstripe information is also in the chip and is being skimmed by evesdropping the chip protocol?

past posts in this thread &/or refs to yes card:
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#16 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#17 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#18 Security Soap Opera
http://www.garlic.com/~lynn/aadsm23.htm#19 Petrol firm suspends Chip&Pin

Reliable Connections Are Not

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 7, 2006 11:06 AM
Subject: Reliable Connections Are Not
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000714.html

we had done a high-speed backbone in the mid-80s and had to address lots of these issues.
http://www.garlic.com/~lynn/subnetwork.html#hsdt

in the late 80s & early 90s were were on the XTP (protocol) technical advisory board ... which had a specification that addressed a number of these issues. one of the participants was from the naval surface warfare center (nswc) ... they were looking at using it for shipboard fire control systems ... and were assuming an extremely hostile environment with possibly significant failure scenarios.

it was also billed as high-speed operation ... including having a reliable datagram delivery.

one of the comparisons that was done at the time was that TCP/IP requires a minimum 7-packet exchange. at the time, there had been work on VMTP (RFC1045) for "reliable" protocol in minimum 5-packet exchange. XTP was specifying a reliable protocol in minimum 3-packet exchange.

misc. past posts mentioning XTP and/or its proposal in ANSI/ISO as high-speed protocol.
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

one of the things that plagued webservers in the early days was that most tcp/ip implementations had assumed relatively long running sessions. as a result, the termination processing had processing of linear lists (FINWAIT). One of the first mismatches between HTTP (as a datagram protocol) implementations in TCP (a session protocol) was when some number of webservers were finding that the CPU was spending 95% of its time running through FINWAIT processing (the high-rate of extremely short sessions was resulting in extremely long FINWAIT lists).

when we were asked to consult with this small client/server startup that wanted to do payment transactions on the server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

which is now comingly referred to as e-commerce. a lot of people assumed that you could take the message format definitions from the payment industry telco circuit-based operation and map it into a tcp/ip packet network. the messages flowed ... but it had none of the traditional telco industry provisioning that come to be implicitly assumed. An early test had a problem and a trouble call logged with the payment transaction trouble desk. the trouble desk nominally expected to do first level problem determination within five minutes elapsed time. three hours later, they were still not able to resolve what was going on and closed it as NTF. another issue was that their SSL technology was dependent on being used in very specific sequence of processes (which is frequently not observed these days).

out of that we spent several week doing a detailed failure mode analysis and coming up with a bunch of documentation and processes as compensating procedures for mapping a telco provisioned circuit operation into a tcp/ip network.

some of this we were able to draw on earlier experience having previously done an extremely detailed vulnerability analysis of tcp/ip protocol as part of turning out our ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

where vulnerability included full gamut of operational type failures as well as possibility of active attacks. recent post mentioning another aspect of this
http://www.garlic.com/~lynn/2006e.html#11 Caller ID "spoofing"

Payment systems - the explosion of 1995 is happening in 2006

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 7, 2006 05:35 PM
Subject: Payment systems - the explosion of 1995 is happening in 2006
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000711.html

slightly related post in a thread about paypal and financial services offerings

it also mentions that several of the digital cash operations in the 90s were structured as a mechanism of acquiring the float on the money in the infrastructure.

in the mid-90s some number of the central banks stated that they would allow the operations to retain the float through startup phases but after that they would be required to start paying interest on the customers' value on deposit in the infrastructure.

this somewhat put a damper on some amount of digital cash ventures related to starting and operating such infrastructures (that they would not be able to count on the large float bonanza):
http://www.garlic.com/~lynn/2006i.html#14

Payment systems - the explosion of 1995 is happening in 2006

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2006 11:43 AM
Subject: Payment systems - the explosion of 1995 is happening in 2006
MailingList: Financial Cryptography
Iang wrote:
Lynn, was that in the US or in Europe? I can well imagine that Mondex were told the float would be regulated ... because they based their business case on such float capture issues and tried to reserve it to Mondex International. Such an amusing selling technique :)

re:
http://www.garlic.com/~lynn/aadsm23.htm#22 Payment systems - the explosion of 1995 is happening in 2006

the central banks I remember making the statement were mostly in europe. many of the "stored value" digital cash systems are at least partially based on float providing financial incentive.

one of the big issues in the early e-check operation was whether the funds would settle immediately electronically or take several days. some of the financial institutions were use to the float operation of the physical check world. this was also raised in the recent check21 mandates and how long would it take funds to actually settle.

with respect to mondex, we had been asked to design and cost an infrastructure for a national deployment ... as part of that we also did a business analysis of the financials. they were looking at charging fees for fund transfers into the card as well as loosing the float. part of this was that the float (originally) effectively all rolled up to mondex international ... so the other institutions in the infrastructure had to recover their costs by other mechanisms.

misc. past posts mentioning float and/or mondex
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
http://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash
http://www.garlic.com/~lynn/aepay11.htm#42 Bank Float May Sink
http://www.garlic.com/~lynn/aadsm14.htm#7 Bank Float May Sink
http://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards?
http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2005i.html#10 Revoking the Root
http://www.garlic.com/~lynn/2005u.html#29 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2005v.html#1 Is Mondex secure?

Reliable Connections Are Not

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2006 02:40 PM
Subject: Reliable Connections Are Not
MailingList: Financial Cryptography
blog:
https://www.financialcryptography.com/mt/archives/000714.html

part of doing ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

we had a bunch of stuff that did ip-address take-over when a server/router failed (we also had stuff to do MAC-address take-over) for fall-over.

part of this was dependent on ARP table time-outs of the ip-address->MAC-address (so a different MAC-address could come in with the same MAC-address).

turns out that it wasn't working very well. there was a bug in bsd tahoe/reno implementation that was in used by a large number of different platforms (so any client platform network code built using the bsd tahoe/reno code base had the problem).

the ip-address to mac-address routine saved the last response from calling the ARP routine. if the next request was for the same ip-address, the code would use the saved response ... rather than (re-)calling the ARP routine. this saved response had no time-out (compared to the table entries managed by the ARP routine). ARP flush command had no effect on this saved value either.

so a large number of client configurations were heavily asymmetric traffic ... nearly all client traffice going through/to a server or router.

so an administrative work-around was to send a packet from a "differnet" ip-address to the list of all clients. this would force the clients ip-address to do a lookup on a different ip-address (resetting the single saved value and forcing a call to the ARP code).

posts in thread:
http://www.garlic.com/~lynn/aadsm23.htm#21 Reliable Connections Are Not
http://www.garlic.com/~lynn/2006i.html#16 blast from the past, reliable communication
http://www.garlic.com/~lynn/2006i.html#17 blast from the past, reliable communication

Petrol firm suspends chip-and-pin

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2006 06:23 PM
Subject: Petrol firm suspends chip-and-pin
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000713.html

this shows a picture of a smart 5000 ped
http://linuxdevices.com/articles/AT5376216178.html

it seems that if you do a magstripe op ... the card goes in horizontal(?) but if you want to do a chip, the card goes in veritically(?). if that is the case, the magstripe wouldn't be read if doing a pin operation?

a possible question was whether chip&pin had an image of the magstripe in the chip which is transferred to the terminal embedded in some protocol chatter. somebody might have specified such a protocol since it would minimize the deployment impact for chip&pin on the rest of the infrastructure (i.e. after some amount of the chip protocol chatter at the terminal ... a payment transaction could go thru a lot of backend processing with the emulated track1&track2 data).

this might account for one of the news items where Shell said that chip&pin was being disabled ... but that transactions could still be done with magstripe swipe.

also this was the chip&pin yes card scenario mentioned in the previous thread, the chip/terminal communication was evesdropped and the skimmed information was used to create a counterfeit (chip&pin) chip
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin

this however shows a more traditional ATM looking card reader
http://www.openpaynews.com/downloads/datasheets/openpayUPT-4000.pdf

another picture (again looks like it is capabile of reading both the magstripe and chip in same operation)
http://www.trintech.com/Unattended-Payment-Terminals-OpenPay-UPT-4000.html

how does it select between doing a magstripe operation vis-a-vis chip operation ... if the card has been inserted in such a way that it reads both?

i found a webpage describing a hybrid emv/magstripe reader that talks about simultaneously reading the magstripe and the emv chip and validating the two sets of information being consistent.

This article dated feb. 7, 2006 talks about being able to skim magstripe on a emv card and using the information to create counterfeit magstripe cards
http://australianit.news.com.au/articles/0,7204,18033140%5E15397%5E%5Enbv%5E,00.html

Petrol firm suspends chip-and-pin

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2006 06:48 PM
Subject: Petrol firm suspends chip-and-pin
MailingList: Financial Cryptography
Chip and pin hack exposed
http://www.theinquirer.net/?article=31547

According to our source, a team of shysters has been turning up at petrol stations posing as engineers and taking the Trintech Smart5000 Chip and Pin units away for repair. They have then bypassed the anti-tamper mechanisms and inserted their own card skimmer.


... snip ...

this is also could be considered from the angle of my old security proportional to risk theme
http://www.garlic.com/~lynn/2001h.html#61

previous posts in this thread:
http://www.garlic.com/~lynn/aadsm23.htm#16 FraudWatch Chip&Pin
http://www.garlic.com/~lynn/aadsm23.htm#17 FraudWatch Chip&Pin
http://www.garlic.com/~lynn/aadsm23.htm#19 Petrol firm suspends Chip&Pin
http://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends Chip&Pin
http://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends Chip&Pin

Chip-and-Pin terminals were replaced by "repairworkers"?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 9, 2006 10:36 AM
Subject: Chip-and-Pin terminals were replaced by "repairworkers"?
MailingList: Financial Cryptography
Shell Chip And PIN Breach - Response From RSA Security
http://www.theitshield.com/pr/7118

can you say security proportional to risk
http://www.garlic.com/~lynn/aadsm23.htm#26 Petrol firms suspends chip-and-pin
and
http://www.garlic.com/~lynn/2001h.html#61
or parameterised risk management
http://www.garlic.com/~lynn/aadsm23.htm#1

note that the chip&pin counterfeit yes card chips mentioned in 2002 reference
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
and
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin

would have involved compromised and/or counterfeit chip&pin readers skimming information (for loading into the counterfeit chips) from the chip&pin protocol chatter.
http://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin

JIBC April 2006 - "Security Revisionism"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 10, 2006 01:11 PM
Subject: JIBC April 2006 - "Security Revisionism"
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000717.html
http://www.arraydev.com/commerce/JIBC/2006-04/Grigg.asp

with respect to comment about doubling costs:
Adi Shamir suggests that to double security we have to double costs [ 11 ]. The specific failings of the '90s generation were an over-attention on a perfect security model, which resulted in usability issues on the one hand, and crowding out other ideas primarily with public key infrastructures ("PKIs") on the other. We will pay the price for this in phishing for the next couple of years, until PKI is overcome.

in the mid-90s, when x9a10 financial standards working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments (in the work on x9.59 standard) ... one of the questions was can you eliminate the vulnerability ... as opposed to providing stronger security as a countermeasure to the vulnerability.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

at the time, skimming was well-established ... harvesting static data for use in replay attacks. at the time, part of this was that the account number was effectively overloaded with both account lookup function (used in large number of different business processes) and effectively, also, as form of authentication. x9.59 addressed the opportunity by establishing that account numbers had nothing at all to do with authentication ... and that that there needed to be dynamic data authentication that was not subject to skimming and replay attacks.
http://www.garlic.com/~lynn/subintegrity.html#harvest

the other thing that was fairly well recognized was man-in-the-middle attacks, especially where authentication was used to bracket some number of operations or transactions. The operations/transactions themselves were performed w/o being directly authenticated. x9.59 required that dynamic data authentication (countermeasure to skimming and reply attacks) be applied directly to all operations (countermeasure to various kinds of man-in-the-middle attacks).
http://www.garlic.com/~lynn/subintegrity.html#mitm

eliminating the vulnerabilities was a significant better approach to providing for cost-effective security, as opposed to attempting to pile-on ever increasing amounts of security to cover up problems. this is somewhat my past serious of posts mentioning that burying the planet under miles of cryptography would never be the solution for several of these vulnerabilities. note that at the time the x9.59 work was starting, there was still quite a bit of gov. & jurisdictional issues around the world with the use of crypto for hiding information, x9.59 changed the paradigm so it was no longer necessary to hide the transaction as fraud countermeasure:
http://www.garlic.com/~lynn/aadsm15.htm#21 Simple SSL/TLS - Some Questions
http://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
http://www.garlic.com/~lynn/2005k.html#56 Encryption Everywhere? (Was: Re: Ho boy! Another big one!)
http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005p.html#24 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
http://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006h.html#26 Security

JIBC April 2006 - "Security Revisionism"

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 10, 2006 03:04 PM
Subject: JIBC April 2006 - "Security Revisionism"
MailingList: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm23.htm#28 "Security Revisionism"

Adi Shamir suggests that to double security we have to double costs [ 11 ]. The specific failings of the '90s generation were an over-attention on a perfect security model, which resulted in usability issues on the one hand, and crowding out other ideas primarily with public key infrastructures ("PKIs") on the other. We will pay the price for this in phishing for the next couple of years, until PKI is overcome.

and with respect to the above comment about the failings of the 90s ... was that some number of these fledgling, new startups calling themselves certification authorities ... had approached the financial industry with a business proposal for certificate manufacturing ... a term we had coined at the time
http://www.garlic.com/~lynn/subpubkey.html#manufacture

the financial institutions would register public keys for each of their accounts and transmit the updated master account file to one of these fledgling, new startup certification authorities. the certification authority would manufacture a digital certificate based on the information in each account record and return the results to the financial institution at only a charge of $100/account/annum. This represented a minimum of $20b/annum transfer of wealth from financial infrastructure to these fledgling certification authority startups.

many in the industry had been convinced that the only security was provided by validating digital signatures using public keys taken from appended digital certificates and there was absolutely no security provided by validating digital signatures using on-file public keys taken from account records (even in cases where the digital certificate content had been totally derived from the same account record).

my observation that this minimum $20b/annum costs for something that provided no incremental security (over using the same information directly from the account record) created a significant barrier to market entry.

one indication of such pervasive belief in the requirment (for digital certificates for digital signature validation), was an effort in the financial standards group on compressed digital certificates. the problem was that typical payment transaction was on the order of 60-80 bytes ... even for relying-party-only certificate infrastructure
http://www.garlic.com/~lynn/subpubkey.html#rpo

would contribute an appended 4k-12k bytes resuling in a transaction payload bloat of 100 times (thousands of bytes rather than tens of bytes)

the objective of the compessed digital certificate effort was attempting to get the appended overhead down on the order of 300 bytes (initially by removing non-unique fields in every certificate).

However, I suggested that even a better method was to remove every field that was already in the possession of the relying party. For the situation where the digital certificate had been totally derived from the financial institution's account record, it was trivially possible to demonstrate compression of a digital certificate to zero bytes. misc. past posts mentioning the enormous payload bloat of normal digital certificates and the significant payload bloat reduction by appending zero-byte digital certificates:
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#10 X.500, LDAP Considered harmful Was: OCSP/LDAP
http://www.garlic.com/~lynn/aadsm17.htm#4 Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#41 Yahoo releases internet standard draft for using DNS as public key server
http://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#5 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#27 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#31 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
http://www.garlic.com/~lynn/aadsm19.htm#11 EuroPKI 2005 - Call for Participation
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
http://www.garlic.com/~lynn/aadsm19.htm#40 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
http://www.garlic.com/~lynn/2003g.html#47 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate
http://www.garlic.com/~lynn/2004g.html#5 Adding Certificates
http://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
http://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#9 Smart card Authentification
http://www.garlic.com/~lynn/2004m.html#23 Help! I'm trying to understand PKI - especially CA's role
http://www.garlic.com/~lynn/2005e.html#22 PKI: the end
http://www.garlic.com/~lynn/2005e.html#38 xml-security vs. native security
http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
http://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#45 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005h.html#25 couple more Q's on basic public key encryption techniques
http://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
http://www.garlic.com/~lynn/2005i.html#4 Authentication - Server Challenge
http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2005l.html#7 Signing and bundling data using certificates
http://www.garlic.com/~lynn/2005l.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#23 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?
http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
http://www.garlic.com/~lynn/2005t.html#6 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2006b.html#37 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#8 Beginner's Pubkey Crypto Question
http://www.garlic.com/~lynn/2006e.html#42 SSL Certificate Signing
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#28 confidence in CA
http://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation

Petrol firm suspends chip-and-pin

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 10, 2006 05:59 PM
Subject: Petrol firm suspends chip-and-pin
MailingList: Financial Cryptography
some of the comments in the news today:

Security Expert Says Chip-And-PIN Facilitates ATM Fraud
http://www.cardtechnology.com/article.html?id=20060510KWGALG2S
'Fraudproof' cards attract scammers
http://www.channel4.com/news/content/news-storypage.jsp?id=447024
'Fraudproof' cards attract scammers
http://www.itn.co.uk/news/index_447024.html
'Fraudproof' cards attract scammers

http://www.itv.com/news/index_447024.html
Old technology aiding identity fraud
http://www.smh.com.au/news/national/old-technology-aiding-identity-fraud-keelty/2006/05/10/1146940613348.html


as mentioned previously, the comment from 2002 on chip&pin yes card
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
and
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin

fraud (which had been going on up to that time), was with respect to compromised or counterfeit terminals skimming the chip&pin protocol chatter ... not (necessarily also) skimming the magstripe.

the chip&pin specification here mentions "track1" and "track2" (i.e. the components of the magstripe) in the chip protocol chatter
http://gsho.thur.de/gsho/technik/download/cardspec.pdf
http://www.ttfn.net/techno/smartcards/termspec.pdf

... this is in addition to having the PIN in the chip protocol chatter.

so one question is whether that information (in the chip protocol) sufficiently similar to that used for the magstripe, that it enables the creation of counterfeit magstripes?

the specification also talks about about the signed static application data ... which was what was used for authentication in the yes card scenarios.

the "dynamic data" (authentication option) in the specification is supposedly a countermeasure to the replay attacks found with the counterfeit (static data) yes cards. one issue may be that since "static data" is part of the specification, 1) can sufficient data be skimmed in a "dynamic data" transaction; and 2) then can that data be used to build counterfeit yes card; and 3) can such a yes card convince terminals to downgrade from "dynamic data" to "static data" operation? a possible alternative scenario is can a compromised or counterfeit terminal convince a "good" chip to downgrade from "dynamic data" to "static data", skim the "static data" ... and then use that to build counterfeit yes cards?

other details in the specification talks about the chip containing sufficient business rules for authorizing offline transactions ... which also contributed to the rise of the yes card label ... aka the terminal would ask an "authenticated" card whether to do an offline transaction, and if YES, also ask the card if the transaction should be approved.

JIBC April 2006 - "Security Revisionism"

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 11, 2006 09:41 AM
Subject: JIBC April 2006 - "Security Revisionism"
MailingList: Financial Cryptography
for your reading pleasure

Security Absurdity: The Complete, Unquestionable, And Total Failure of Information Security.
http://www.securityabsurdity.com/failure.php

and of course, old post on thread between information security and risk management
http://www.garlic.com/~lynn/aepay3.htm#riskm
and security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

with respect to one of the references in the above article, some old news items (not sure if they are all still active):

Cybercrime Profits Outpace Drug Trafficking
http://www.ecommercetimes.com/story/47559.html
Expert: Cyber-crime Yields More Cash than Drugs
http://www.eweek.com/article2/0,1895,1893592,00.asp
Expert: Cyber-crime Yields More Cash than Drugs

http://www.extremetech.com/article2/0,1697,1893916,00.asp
Cybercrime now outstrips drug trafficking
http://www.cw360asp.com/Articles/2005/11/29/213190/Cybercrimenowoutstripsdrugtrafficking.htm
Cybercrime 'more lucrative' than drugs
http://www.theregister.co.uk/2005/11/29/cybercrime/
Cybercrime profits exceed those of drugs, expert says
http://www.globetechnology.com/servlet/ArticleNews/TPStory/LAC/20051129/RTICKERB29-2/TPTechnology/
Cybercrime yields more cash than drugs
http://news.com.com/Cybercrime+yields+more+cash+than+drugs/2100-7348_3-5973918.html
Cybercrime 'more lucrative' than drugs
http://www.theregister.com/2005/11/29/cybercrime/
Cybercrime 'more lucrative' than drugs
http://www.channelregister.co.uk/2005/11/29/cybercrime/
Cybercrime more profitable than illicit drug sales?
http://arstechnica.com/news.ars/post/20051129-5648.html


Chip-and-Pin terminals were replaced by "repairworkers"?

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 11, 2006 09:54 AM
Subject: Chip-and-Pin terminals were replaced by "repairworkers"?
MailingList: Financial Cryptography
more in the on going saga

Lloyds TSB admits chip and Pin flawed
http://www.thisismoney.co.uk/saving-and-banking/article.html?in_article_id=408976&in_page_id=7
Bank admits flaws in chip and PIN security
http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=385811&in_page_id=1770
Surge in overseas ATM fraud
http://www.itn.co.uk/news/business_341509.html
Surge in overseas ATM fraud
http://www.channel4.com/news/content/news-storypage.jsp?id=341509


in 2000 there was a one week conference in London with the Lloyds of London syndicates that provide retail fraud insurance. One of the subjects discussed extensively was the threat model involving compromised and counterfeit terminals for things like skimming ... as well as x9.59 characteristic of having eliminated requirement to hide the transaction as fraud countermeasure.

slight cross-over
http://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"

Chip-and-Pin terminals were replaced by "repairworkers"?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 11, 2006 10:30 AM
Subject: Chip-and-Pin terminals were replaced by "repairworkers"?
MailingList: Financial Cryptography
Iang wrote:
Lynn, who/which was taking out the insurance? Why weren't they self-insuring? It seems with such a large and spread population only self-insurance makes sense?

re:
http://www.garlic.com/~lynn/aadsm23.htm#32 Chip-and-Pin terminals were replaced by "repairworkers"?

retail merchants (brick&mortar) ... many places in the world.

for payment cards ... the retail merchant having fraudulent transactions is held liable for the transactions. standard dispute process ... and burden of proof is on the merchant in any dispute.

for a little drift ... a few past posts mentioning disputes
http://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
http://www.garlic.com/~lynn/aadsm15.htm#8 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#55 MD5 collision in X509 certificates
http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
http://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#22 ID "theft" -- so what?
http://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world

Chip-and-Pin terminals were replaced by "repairworkers"?

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 11, 2006 04:20 PM
Subject: Chip-and-Pin terminals were replaced by "repairworkers"?
MailingList: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm23.htm#32 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#33 Chip-and-Pin terminals were replaced by "repairworkers"?

looking at the threat model for compromised and/our counterfeit terminals was attempting to get a feeling for production of counterfeit cards that could be used at other merchants for fraudulent transactions (and therefor overall merchant fraud).

the early x9.59 protocol analysis from the mid-90s had the transaction being directly authenticated.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

separation of authentication from the actual operations tends to mimick more of session type paradigm. however, session type paradigm (with authentication separate form actual operations), tends to be more vulnerable to end-point compromises, infrastructure compromises, replay attacks, mitm-attacks, etc.

In the past, physical compromises of end-points (like terminals) or infrastructure (like networks) have tended to involve evesdropping and harvesting related exploits. the attackers would take the gathered information and use it for mounting attacks on other parts of the infrastructure. Part of this can be viewed from the standpoint of fraud ROI ... it takes some amount of investment to put into play compromised (or counterfeited) end-points amd/or other parts of the infrastructure (like network). Using information from the exploit to attack other parts of the infrastructure, draws attention and suspicion away from the the point of exploit (tending to maximise its criminal operation). Performing fraudulent transactions at the point of exploit tends to focus suspicion much quicker, the implication that the point of exploit will be discovered and have a much shorter useful (criminal) lifetime. This has tended to be the model for compromised and/or counterfeit terminals.

However, the economics somewhat change in the online/virtual world. Getting a trojan/virus into a personal computer end-point tends to represent much lower investment. The trojan/virus can operate as a compromised terminal, havesting/skimming information that enables attacks at other points of the infrastructure. However, the trojan/virus can also be used to directly perform fraudulent operations. This may shorten the life expectency of the trojan/virus ... but it doesn't take a lot of such fraud for an attacker to recover their expenses.

as oft repeated before, the requirements given the x9a10 standards working group for x9.59 standard was to preserve the integrity of the financial infrastructure for ALL retail payments.

part of those requirements, implied x9.59 requiring dynamic data authentication (digital signatures) as countermeasure to skimming/harvesting (potentially by compromised or counterfeit end-points) and replay attacks.
http://www.garlic.com/~lynn/subintegrity.html#harvest

however, it also implied that authentication be applied directly to the transaction, drastically reducing the susceptability to various kinds of other end-point and infrastructure vulnerabilities as well as mitm-attacks.
http://www.garlic.com/~lynn/subintegrity.html#mitm

misc. past posts mentioning compromised and/or counterfeit terminals.
http://www.garlic.com/~lynn/aadsm19.htm#38 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm22.htm#44 Creativity and security
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#32 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004l.html#31 Shipwrecks
http://www.garlic.com/~lynn/2005g.html#41 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?

3 of the big 4 - all doing payment systems

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 12, 2006 02:35 PM
Subject: 3 of the big 4 - all doing payment systems
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000715.html

... slight drift, another article from today

Payments Technologies Vie For Banks' IT Dollars
http://web.archive.org/web/20060526221137/http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1147439455861413176&block=

from above:

Payments revenues at European banks typically represent 10 per cent of annual revenues, while in the US, this figure is nearer to 40 per cent


... snip ...

some difference in the revenue demographics between US and Europe with regard to payment operations

3 of the big 4 - all doing payment systems

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 12, 2006 04:45 PM
Subject: 3 of the big 4 - all doing payment systems
MailingList: Financial Cryptography
Iang wrote:
Off to Washington DC they trotted and fairly soon on, the message filtered back to Microsoft - that's not a good idea, pick on someone else's soft underbelly.

re:
https://www.financialcryptography.com/mt/archives/000715.html

a congressman's speech on the floor of the senate about the bank modernization act said that the purpose of the bill was if you are already a bank, you can remain a bank and if you aren't already a bank, you can't be a bank, and the bill was to specificially prevent microsoft and wal-mart from becoming banks.

a couple other articles from today:

Small Banks Adopt a Wide Spectrum of Electronic Payments
http://www.digitaltransactions.net/newsstory.cfm?newsid=944

Home Depot: No Designs on Payments with Deal to Buy ILC
http://www.digitaltransactions.net/newsstory.cfm?newsid=945

from above:

Less than a month after the Federal Deposit Insurance Corp. held three days of unprecedented hearings on Wal-Mart's application to open a Utah ILC, Atlanta-based Home Depot this week disclosed a definitive agreement to buy EnerBank USA, a Salt Lake City-based ILC with $75 million in net loan assets.

... snip ...

3 of the big 4 - all doing payment systems

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 13, 2006 02:10 PM
Subject: 3 of the big 4 - all doing payment systems
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000715.html
http://www.garlic.com/~lynn/aadsm23.htm#35 3 of the big 4 - all doing payment systems
http://www.garlic.com/~lynn/aadsm23.htm#36 3 of the big 4 - all doing payment systems

another aspect of the payment industry landscape:

Interchange Fees: The tipping point
http://www.cyberwarzone.com/united-states-leaking-1tb-data-daily-foreign-countries


from above
Fed up with out-of-control interchange fees, retailers are fighting back with concerted legal and educational tactics -- and, in some cases, proactive offensives of their own.

... snip ...

http://www.epaynews.com/newsletter/epaynews322.html


from above:
Convenience store operators can make more money on a 12-ounce cup of coffee than they can on a 12-gallon tank of gas. Credit card fees now account for almost half of a typical store's expenses - more than labor.

... snip ...

this is sort of another facet of Boyd OODA-loops ... not only do you cycle the loops faster ... but during the loop you may also view a subject from a number of different aspects.
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

NSA knows who you've called

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: NSA knows who you've called.
Date: Sat, 13 May 2006 17:02:57 -0600
To: cryptography@xxxxxxxx
dan@xxxxxxxx wrote:
You and I are in agreement, but how do we get the seemingly (to us) plain truth across to others? I've been trying for a good while now, reaching a point where I'd almost wish for a crisis of some sort as persuasiveness is not working.

for other drift ... the stuff about call record analysis with regard to social networking has been topic in datamining conferences for the past several years ... both academia and industry. the cellphone companies appear to be especially interested in it, for various kinds of capacity planning and marketing purposes (I think some academia even have contracts with cell phone companies researching this area).

several months ago my wife had extensive communication with an editor doing some background stuff on datamining. some of it showed up in an article somewhat spun for the current situation

Info Mining & Sharing are Controversial Co-Dependents, part 1:
http://www.publicsectorinstitute.net/ELetters/EGovernment/v4n7/May13Articles.lsp#DataMining

my wife's quotes liberally lace part 2:

Data Mining "Disrupts & Enables"
http://www.publicsectorinstitute.net/ELetters/EGovernment/v4n7/May13Articles.lsp#DataMining2

Tracking you, tracking me, tracking everyone

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 14, 2006 10:46 AM
Subject: Tracking you, tracking me, tracking everyone
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000704.html

minor related reference from crypto list posting
http://www.garlic.com/~lynn/aadsm23.htm#38 NSA knows who you've called

there was some recent announcement (I forget where I saw it) that somewhere they are going to start sending location specific advertisements to your cellphone ... as you move from place to place ... they will transmit advertisements to your cellphone that are specific to your current physical location.

Markets in Imperfect Information - Lemons, Limes and Silver Bullets

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 15, 2006 11:27 AM
Subject: Markets in Imperfect Information - Lemons, Limes and Silver Bullets
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000721.html

part of this drifts into the area when something appears to be valuable ... and there are items that are taken as representations of that something ... then you have people inclined to fraud. in various of my postings on credentials, certificates, diplomas, licenses, etc that have served for centuries as representation paradigm (for replying parties that have no direct knowledge and/or means of obtaining that knowledge) ... education has become a valuable commodity and diplomas that are taken as representation of education, are now being fabricated (either fraudulent and/or in diploma mills).

this is the scenario that there are various facts ... and for centuries; credentials, certificates, diplomas, and licenses have been used to represent various facts for relying parties that have not the means of directly accessing the facts themselves. with advances in dataprocessing and online networks there are fewer and fewer circumstances where relying parties can't find some means of accessing the facts ... drastically reducing the situations where separate and distinct credentials, certificates, diplomas, and/or licenses are required (as a means of representing such facts).

this is sort of the certificate sticker on the window of a used car vis-a-vis getting something like a carfax report.

misc. past posts mentioning the centuries old paradigm of credentials, certificates, diplomas and/or licenses for relying parties that don't have any other means of accessing the information
http://www.garlic.com/~lynn/aadsm23.htm#0 Separation of Roles - an example
http://www.garlic.com/~lynn/aadsm23.htm#5 History and definition of the term 'principal'?
http://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/2006c.html#13 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#39 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#36 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#39 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#28 confidence in CA
http://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation

3 of the big 4 - all doing payment systems

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 15, 2006 11:37 PM
Subject: 3 of the big 4 - all doing payment systems
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000715.html
http://www.garlic.com/~lynn/aadsm23.htm#35 3 of the big 4 - all doing payment systems
http://www.garlic.com/~lynn/aadsm23.htm#36 3 of the big 4 - all doing payment systems
http://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems

Plastic under attack. Battling lawsuits and new rivals, MasterCard and Visa may face a lower-growth future.
http://money.cnn.com/magazines/fortune/fortune_archive/2006/05/29/8377961/index.htm


....

ECOM Finds Issuer for Anonymous, Disposable Prepaid MasterCard
http://www.digitaltransactions.net/newsstory.cfm?newsid=954


from above

... allows the company to sell the cards to consumers through merchants like cans of soda or other merchandise, then process transactions almost immediately at any location that takes MasterCard

... snip ...

Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
Date: Tue, 16 May 2006 17:24:53 -0600
To: Cryptography <cryptography@xxxxxxxx>
http://www.garlic.com/~lynn/rfcidx14.htm#4492

4492 I
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS), Blake-Wilson S., Bolyard N., Gupta V., Hawk C., Moeller B., 2006/05/16 (35pp) (.txt=72231) (Refs 2246, 3268, 3279, 3280, 4346, 4366) (was draft-ietf-tls-ecc-12.txt)

Spring is here - that means Pressed Flowers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 22, 2006 12:37 PM
Subject: Spring is here - that means Pressed Flowers
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000729.html

the referenced digital money blog ... in turn has a reference to Schneier's blog on multi-use smartcards ... which has a post mentioning the amex blue card for consumer use.
http://www.schneier.com/blog/archives/2006/02/multiuse_id_car.html

part of the program was giving away "free" smartcard readers. at the time the "pc/sc" standard only supported serial port ... and the distributed smartcard readers were serial port devices. consumers had horrendous problems with getting serial port smartcard readers installed and operational. there were horror tales about 1hr customer call center conversations that were unable to resolve and large number of stories about repeated blue screens of death during install attempts and even people being forced to re-install their systems from scratch.

this experience with serial port pc/sc eventually resulted in an industry opinion that smartcards were not viable in the consumer market segment. it was also during this period that m'soft announced they were canceling their smartcard operating system project.

there was subsequent effort that upgraded pc/sc standard to USB plug&play, which turned out to address many of the problems experienced during the earlier activity with serial port smartcard readers. however, by this time, there was a fairly widespread opinion that smartcards were not viable in the consumer market segment.

for total drift ... i have slight quible with some nomenclature differentiating multi-application smartcards and multi-function smartcards.

it is possible to have a chipcard that just does a single function ... like authentication ... and that single function can be used in a large number of different applications ... resulting in it being a multi-application card (even if the chip only does a single function).

that is separate from multi-function smartcards that implement lots of different functions possibly for use in a wide-variety of different applications. part of the approach of the multi-function smartcards was left from the 80s & 90s when they were supposed to be the low-end portable computing vehicle ... only to find that they were displaced from that market segment by PDAs and cellphones.

recent ref (last part of the post) consulting with gov. lab in the early 90s on trying to move gov. technology into commercial sector ... including some smartcard technology
http://www.garlic.com/~lynn/2006k.html#25

part of this orientation has also led to things like embedding significant business rules in the smartcard ... this was at least part of the issue with the yes card exploits mentioned in previous threads
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin

ThreatWatch - markets in loss, Visa's take, 419 "chairmen"

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 23, 2006 07:52 PM
Subject: ThreatWatch - markets in loss, Visa's take, 419 "chairmen"
MailingList: Financial Cryptography
https://www.financialcryptography.com/mt/archives/000727.html

a couple years ago a study was published claiming that 70percent of identity theft involved insiders. so in much the same way that the amateurs provide cover for the professionals ... all the attention placed on intrusion prevention and outsider countermeasures can cloak the activities of the insiders.

at some point embezzlement and things like the S&L crisis represented more of a threat to financial institutions than the guys with guns.

old post discussing the S&L crisis (among other things)
http://www.garlic.com/~lynn/aepay3.htm#riskm

Status of SRP

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of SRP
Date: Fri, 02 Jun 2006 19:09:41 -0600
To: cryptography@xxxxxxxx
Florian Weimer wrote:
If you've deployed two-factor authentication (like German banks did in the late 80s/early 90s), the relevant attacks do involve compromised customer PCs. 8-( Just because you can't solve it with your technology doesn't mean you can pretend the attacks don't happen.

EU finread terminal was countermeasure to (widely held impression that) PCs are extremely vulnerable to compromise.
http://www.garlic.com/~lynn/subintegrity.html#finread

card authentication required pin entry to work ... and finread terminal had its own PIN-pad distinct from the vulnerable PC keyboard. orientation was towards transaction authentication ... with the finread terminal also having its own display of what was being authentication. the transaction authentication orientation was countermeasure to session authentication orientation where PC compromises could operate within the boundaries of any authenticated session.

part of thread in sci.crypt mentioning finread terminal as countermeasure to (widely held view of) the ease of PC compromises
http://www.garlic.com/~lynn/2006k.html#46 Keylogger resistance
http://www.garlic.com/~lynn/2006k.html#52 Keylogger resistance

Status of opportunistic encryption

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of opportunistic encryption
Date: Fri, 02 Jun 2006 19:16:05 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx
James A. Donald wrote:
I was unaware of this. So I googled for DNSSEC. Reading the DNSSEC documents I found

: : In order to support the larger DNS message
: : sizes that result from adding the DNSSEC RRs,
: : DNSSEC also requires EDNS0 support ([RFC
: : 671]).

and

: : its authentication keys can be authenticated
: : by some trusted means out of band from the
: : DNS protocol.

This does not sound workable to me.


this could be analogous or the same as the trusted certification authority authentication keys that are incorporated into browsers when they are distributed (to the extent that distributed certification authority authentication keys, that are authenticated out of band from the standard PKI process, appear to work, it could be possible that something similar might also work for DNS).

the specification of the root DNS servers could include specifying the associated authentication keys ... in much the same way that the distribution of the root CAs information include the distribution of the associated CA authentication keys.

my rfc index
http://www.garlic.com/~lynn/rfcietff.htm

select Term (term->RFC#) under RFCs listed by ... and then select "DNSSEC" in the Acronym fastpath.

domain name system security (DNSSEC )
see also domain name system, domain name system extensions, security
4509 4470 4431 4398 4322 4310 4035 4034 4033 3845 3833 3755 3658 3226 3225 3130 3110 3090 3008 3007 2931 2930 2845 2541 2540 2539 2538 2537 2536 2535 2137 2065


in frames mode, clicking on the RFC number brings up the RFC summary in the lower frame. clicking on the ".txt=nnnn" field in the RFC summary retrieves the actual RFC.

Status of opportunistic encryption

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of opportunistic encryption
Date: Fri, 02 Jun 2006 19:41:55 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx
re:
http://www.garlic.com/~lynn/aadsm23.htm#46 Status of opportunistic encryption

oh, and some number of certification authorities actually backed some parts of DNSSEC ... including the idea that people register a public key when they registered a domain name. this was countermeasure to various kinds of domain name hijacking vulnerabilities ... i.e. the domain name owner would digitally sign communication ... and the domain name infrastructure would validate the digital signature with the onfile public key.

this became attractive to certification authorities. currently they require a ssl domain name certificate application to supply a lot of identification information. the certification authority then performs the time-consuming, error prone, and expensive process of matching the supplied identification information with the information on file with the domain name infrastructure. with communication authenticated with the onfile public keys, there is a reduction in the chance of domain name hijacking ... and therefor the certification authority has higher level of assurance that they aren't dealing with a ssl domain name certificate applicant that has just hijacked the domain name.

also, if the public keys were on file with the domain name infrastructure, then certification authorities could require that application for ssl domain name certificates be digitally signed. then the certification authorities could change from a time-consuming, error prone, and expensive process of matching identification information to the less-expensive and more reliable process of simply authenticating the digital signature. they would execute dnssec protocol with the domain name infrastructure requesting real-time retrieval of the onfile public key for the domain name. they would validate the response with DNSSEC trusted root public key on file in their local repository of trusted dnssec public keys (in much the same way that the existing PKI infrastructure validate digital signatures on digital certificates using CA public key from their local repository of trusted (CA) public keys).

This whole thing then goes to the root of improving the integrity of the SSL domain name certificate infrastructure.

The catch-22 for the certification authority infrastructure is that if they can start retrieving real-time public keys for authenticating digital signatures on ssl domain name certificate applications ... then possibly the rest of the world could also start using DNSSEC to also do real-time retrieval of onfile public keys from the domain name infrastructure.

one might even imagine a highly optimized SSL type session protocol where instead of the existing protocol chatter exchange ... the servers on-file public key could piggyback on the standard DNS response for hostname->ipaddress. the client in the initial transmission send a random session key encrypted with the server's public key.

a few recent posts mentioning this catch-22 dilemma for the SSL domain name certificate industry:
http://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor

Status of opportunistic encryption

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of opportunistic encryption
Date: Fri, 02 Jun 2006 20:09:55 -0600
To: cryptography@xxxxxxxx
James A. Donald wrote:
In an organization with hundreds of administrators managing tens of thousand of machines, what goes wrong with trusting your key store? And who administers Kerberos? Don't they have a problem with tens of thousands of machines?

the original pk-init draft for kerberos just had public keys being registered in lieu of passwords ... in much the same way that people register public keys as part of the "registration authority" part of a pki certification authority process.
http://www.garlic.com/~lynn/subpubkey.html#kerberos

machines then could have public keys to authenticate communicating with the trusted public key store (imagine it like real-time access to a certification authority ... in lieu of the stale, static digital certificates). to the extent that such machines can trust a repository of trusted certification authority public keys ... then they could also have a trusted repository of public keys for real-time communication with key store (where a key store might also be replicated for availability and scaling ... in manner analogous to the way DNS had replicated trusted servers).
http://www.garlic.com/~lynn/subpubkey.html#certless

it was only later that the draft succumbed to the pressure to also allow PKI digital certificate mode of operation ... i.e. the machines rather than doing real-time authenticated communication with the trusted key store ... they might also use a local trusted public key repository to authentication certification authority digital signatures on stale, static digital certificates.

basically the key registration process is identical in the PKI digital certificate mode of operation and the certificate-less public key mode of operation. the management of the trusted public key repository (of trusted "root keys" ... in one case for certification authorities, in the other case for the key store) on each machine is effectively also identical. however, the certificate-less public key mode uses real-time communication with the key store ... while the PKI digital certificate mode substitutes the whole digital certificate issuing, management, administrative, etc infrastructure overhead (in lieu of the much simpler real time communication).

Status of SRP

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of SRP
Date: Sat, 03 Jun 2006 07:01:57 -0600
To: Florian Weimer <fw@xxxxxxxx>
CC: cryptography@xxxxxxxx
Florian Weimer wrote:
FINREAD is really interesting. I've finally managed to browse the specs, and it looks as if this platform can be used to build something that is secure against compromised hosts. However, I fear that the support costs are too high, and that's why it hasn't caught on in retail online banking.

re:
http://www.garlic.com/~lynn/aadsm23.htm#45 Status of SRP

if they can build a $100 PC ... you think that they could build a finread terminal for a couple bucks. sometimes there are issues with volume pricing ... you price high because there isn't a volume and there isn't a volume because you price high.

there is one issue missing from the actual FINREAD specification.
http://www.garlic.com/~lynn/subintegrity.html#finread

when we were doing X9.59 financial standard ... we allowed for a digital signature for authentication as well as for a digital signature from the environment that the transaction was performed in. the issue from a relying party standpoint ... is what assurances do they have as to the actual environment that a transaction was executed in. consumers could claim they were using a FINREAD terminal when they weren't. counterfeit FINREAD terminals could be out in the wild.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

part of the x9.59 financial standard looked at the assurance/integrity that a relying party might have with regard to the actual authentication ... one factor, two factor, three factor ... and the actual assurance/integrity of the associated factors (or conversely, how vulnerable were the factors to compromise). this somewhat led into also having to consider the assurance/integrity environment that the authentication took place in (and what assurances would a relying party have with regard to the environment).

part of it has been some past inclination to just specify some standard ... w/o regard to how a relying party might actual have assurances as to whether some standard or another was being followed in an open environment (and considering threat scenarios that might involve compromise/impersonation/counterfeit of various components).

for instance, there was a recent scenario in the UK where crooks were impersonating maint. people and were updating secure POS terminals with compromised components.

Status of SRP

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of SRP
Date: Sat, 03 Jun 2006 07:44:38 -0600
To: Florian Weimer <fw@xxxxxxxx>
CC: cryptography@xxxxxxxx
Anne & Lynn Wheeler wrote:
if they can build a $100 PC ... you think that they could build a finread terminal for a couple bucks. sometimes there are issues with volume pricing ... you price high because there isn't a volume and there isn't a volume because you price high.

re:
http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP

another aspect was that there was a program in the past to give away smartcards and card readers to consumers as part of doing smartcard financial transactions. the issue at the time was that deployed support for pc/sc standard only supported pc serial port interfaces ... and therefor the free card reader was a serial port device. there was an ensuing disaster as consumers tried to get the serial port device operational ... lots of stories of BSOD, having to re-install everything from scratch, etc. as the dust was settling, there was a quickly spreading opinion that smartcards (or at least smartcard readers) were not viable in the consumer market segment. it was during this period that m'soft even canceled its smartcard operating system project.

recent post discussing the subject:
http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers

Status of opportunistic encryption

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of opportunistic encryption
Date: Mon, 05 Jun 2006 06:39:46 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx
James A. Donald wrote:
For DNS security to work at acceptable cost, authentication has to be in band (perhaps the client is more trusting of certificates signed by a root authority that it has been seeing frequently for a long time, supplemented ad hoc by whitelists and blacklists as the need arises) and the certificates have to create only a small additional overhead.

the only thing that makes a trusted root authority, a trusted root authority is that the relying party has acquired the root authority's public key out-of-band.

all the DNS clients in the world work out of band ... and have forever ... they are told (by the isp) what value to point DNS trusted root(s) ... or are told to setup bootp/dhcp for a specific (supposedly trusted) subnet ... and their ip-address, trusted dns setup, etc ... is supplied for them. one incremental change would be to bootp/dhcp for the client to receive the trusted DNS public key at the same time the client receives the trusted DNS ip-address. of course, then bootp/dhcp represents the trusted root ... and then you might need to add incremental security to the bootp/dhcp process.

the current issue is adding some sort of dynamic data authentication mechanism to the current static values (like the ip-address) ... static values are well known for spoofing and replay attacks. the current issue isn't that DNS doesn't currently have an enormous trust infrastructure ... it is adding additional security and countermeasures to various vulnerabilities

in-band trust processes have tended to be incremental ... the relying party gets a token (like a public key) on initial contact. the relying party remembers that token and the associated context. initially there is little or no trust ... other than on each encounter that the relying party is the same entity that they had delt with before. the relying party keeps a knowledge base on encounters and develops trust based on multiple encounters.

certificates that fit inside single UDP datagram was somewhat the x9 "compression" certificate standard ... trying to get a certificate on the order of 300 bytes. basically it was throwing out all superfluous and redundant information ... and/or anything that was already in the financial institution's possession.

the issue in the mid-90s was that the financial institutions had already realized that x.509 identity certificates for customers represented enormous privacy and liability issues ... and had moved to relying-party-only certificates ... basically only containing public key, account number and all the CPS type gorp.
http://www.garlic.com/~lynn/subpubkey.html#rpo

the problem was that the typical payment transaction is on the order of 60-80 bytes ... and the appended PKI overhead (even for relying-party-only certificates) was running 4k-12k bytes (two orders of magnitude payload bloat ... i.e. 100 times payload bloat).

it was trivial to show that the account number was already in the transaction payload ... and the customer's public key was already on file at the financial institution (they had to register their public key with their financial institution in order to have been issued the relying-party-only certificate; note that registering their public key was an out-of-band process).

as a result, it was possible to trivially demonstrate that the account number and the public key could also be removed from the certificate. after that, it was a trivial process to demonstrate that the rest of the digital certificate could be compressed to zero bytes (by comparison even a 300 byte, compressed certificate still represented a payload bloat of five times for redundant and superfluous information)

by comparison, it was possible to show that digitally signed x9.59 financial standard transaction
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

with appended digital certificates compressed to zero bytes easily fit within a UDP size datagram. compressed, zero byte digital certificates was an alternative to shipping x9.59 w/o any appended certificates at all
http://www.garlic.com/~lynn/subpubkey.html#certless

Status of opportunistic encryption

To: cryptography@xxxxxxxx
Subject: Re: Status of opportunistic encryption
Date: Mon, 05 Jun 2006 07:03:19 -0600
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
CC: James A. Donald <jamesd@xxxxxxxx>
re:
http://www.garlic.com/~lynn/aadsm23.htm#46 Status of opportunistic encryption
http://www.garlic.com/~lynn/aadsm23.htm#47 Status of opportunistic encryption
http://www.garlic.com/~lynn/aadsm23.htm#48 Status of opportunistic encryption
http://www.garlic.com/~lynn/aadsm23.htm#51 Status of opportunistic encryption

oh, and for bootp/dhcp information .... my rfc index
http://www.garlic.com/~lynn/rfcietff.htm

and click on Term (term->RFC#) in the RFCs listed by section.

select "BOOTP" and/or "DHCP" from the Acronym fastpath section

bootstrap protocol (BOOTP )
see also configuration , reverse address resolution protocol
2132 1542 1534 1533 1532 1497 1395 1084 1048 951


dynamic host configuration protocol (DHCP )
see also configuration , host , reverse address resolution protocol
4477 4436 4390 4388 4361 4332 4280 4243 4242 4174 4076 4039 4030 4014 3993 3942 3927 3925 3898 3825 3736 3679 3646 3634 3633 3594 3527 3495 3456 3442 3397 3396 3361 3319 3315 3256 3203 3118 3074 3046 3041 3011 3004 2939 2937 2855 2610 2563 2489 2485 2322 2242 2241 2132 2131 1541 1534 1533 1531


the index in "frame" mode has the RFC summaries in the lower frame. clicking on any RFC number (in the Term->RFC# index), brings up that RFC summary in the lower frame. clicking on the ".txt=nnn" field in the RFC summary, retrieves that actual RFC.

possibly the two largest deployed authentication infrastructures are Kerberos and Radius.
http://www.garlic.com/~lynn/subpubkey.html#kerberos
http://www.garlic.com/~lynn/subpubkey.html#radius

Both have done implementations where the client has registered a public key and then authenticates using a digital signature, verified with the onfile public key (in much the same way that digital signatures on digital certificates are verified with onfile public keys of certification authorities).

for broadband ISP users, the trust root typically just directly drops into DHCP to obtain various internet configuration information supplied by the ISP.

for dial-up users, the initial connection is PPP (long time ago it was SLIP) where the client supplies a userid and some authentication information that is validated from onfile information. then the connection will move to DHCP for the rest of the configuration information.

point-to-point protocol (PPP )
4448 4334 4332 4058 3818 3817 3772 3770 3748 3627 3573 3545 3544 3518 3437 3373 3355 3353 3337 3336 3255 3241 3186 3153 3145 3079 3078 3070 3056 3032 3021 2878 2844 2835 2823 2759 2716 2701 2687 2686 2661 2637 2615 2516 2509 2507 2492 2491 2484 2472 2433 2420 2419 2364 2363 2290 2284 2153 2125 2118 2097 2043 2034 2023 1994 1993 1990 1989 1979 1978 1977 1976 1975 1974 1973 1969 1968 1967 1963 1962 1915 1877 1841 1764 1763 1762 1717 1663 1662 1661 1638 1619 1618 1598 1570 1552 1549 1548 1547 1474 1473 1472 1471 1378 1377 1376 1334 1333 1332 1331 1220 1172 1171 1134


remote authentication dial in user service (RADIUS )
see also authentication , network access server , network services
4372 4014 3580 3579 3576 3575 3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058


kerberos
see also authentication , generic security service , security
4430 4402 4121 4120 3962 3961 3244 3129 2942 2712 2623 1964 1510 1411


Status of SRP

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of SRP
Date: Tue, 06 Jun 2006 09:48:52 -0600
To: Florian Weimer <fw@xxxxxxxx>
CC: cryptography@xxxxxxxx
Florian Weimer wrote:
You mean something like remote attestation? I find it hard to believe that this capability is available today in a relatively open environment, on a platform supporting multiple applications developed by different applications.

re:
http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP

i got involved in tracking down a virus/trojan like problem in the 70s on the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

basically if you are going to allow loading of stuff that can do its own execution w/o many safeguards ... you are going to be extremely vulnerable to numerous kinds of attacks.

either you have to very tightly control what applications are loaded .... or possibly do a fixed function deployment that can support multiple different applications ... possibly based on some form of data driven architecture (i.e. the data specification possibly adapts the functional operation to different applications w/o requiring loading of executable code).

we had done the AADS chip strawman this way ... basically single function operation w/o any ability to load executable code ... that was adaptable to a large number of different applications
http://www.garlic.com/~lynn/x959.html#aads

another possible solution is very strong partitioning of any loadable executable content that is allowed extremely limited/controlled capability.

in the 60s as an undergraduate, i had done a lot with extremely controlled partitioning ... which i learned much later got used in various environments that had extremely high integrity requirements ... random drift
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

i had this discussion with the general manager of the business unit that included java and java virtual machine (when it was in its very early infancy) ... turns out that I had done some work with the person (general manager) nearly 20 years earlier in a different life.

many of the modern generation of POS terminals are trying to cope with this problem ... getting all sorts of frequent application downloads of various kinds ... and still attempting to operate within constraints of their trusted security module implementation.

basically if finread
http://www.garlic.com/~lynn/subintegrity.html#finread

is countermeasure to widely acceptable PC vulnerabilities (many that arise because of the ease and common practice of loading executable content) ... then if you deploy such a finread terminal that is operated using similar conventions ... then it will acquire similar vulnerability characteristics (as the environment that it is suppose to be a countermeasure for).

Status of SRP

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Status of SRP
Date: Wed, 07 Jun 2006 05:39:35 -0600
To: cryptography@xxxxxxxx
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
http://www.garlic.com/~lynn/subpubkey.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/subintegrity.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 numbers, and it would still be unable to prevent account number leakage. 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 (which became the trusted computing effort you are referring to)

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

UK Detects Chip-And-PIN Security Flaw

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: cryptography@xxxxxxxx
Subject: UK Detects Chip-And-PIN Security Flaw
Date: Wed, 07 Jun 2006 07:21:44 -0600
UK Detects Chip-And-PIN SecurityFlaw
http://www.cardtechnology.com/article.html?id=20060606I2K75YSX

APACS says the security lapse came to light in a recent study of the authentication technology used in the UK's new "chip-and-PIN" card system.


... snip ...

this was documented as the yes card in 2002 regarding chip&pin rollouts that had been done in the 99-2002 time-frame

since the yes card vulnerability is an attack against the pos terminal (not the card) ... and since the vulnerability is part of the standard ... even if all new cards were rolled with the "fix" ... the infrastructure might still be vulnerable if POS terminals could be convinced to communicate using the vulnerable standard (this is somewhat analogous to protocol attacks and convincing parties to downgrade to lower encryption).

misc. posts discussing the yes card vulnerability as well as mentioning possible man-in-the-middle attack against the fix for yes card vulnerability.
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
http://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
http://www.garlic.com/~lynn/aadsm18.htm#20 RPOW - Reusable Proofs of Work
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
http://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004j.html#39 Methods of payment
http://www.garlic.com/~lynn/2004j.html#44 Methods of payment
http://www.garlic.com/~lynn/2005u.html#13 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006k.html#1 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006l.html#27 Google Architecture

UK Detects Chip-And-PIN Security Flaw

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: UK Detects Chip-And-PIN Security Flaw
Date: Wed, 07 Jun 2006 09:43:06 -0600
To: cryptography@xxxxxxxx
CC: jamesd@xxxxxxxx, fw@xxxxxxxx
re:
http://www.garlic.com/~lynn/aadsm23.htm#54 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/2006l.html#32 Google Architecture

as i mentioned, the x9a10 financial standards working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments .... this included at least all kinds of internet, all kinds of POS, and all kinds of payments (debit, credit, stored-value, etc).

part of the outcome of the resulting x9.59 financial standard was transaction authentication. session authentication had been looked at, and it was felt (compared to transaction authentication), that it was much more vulnerable to end-point threats, mitm threats, as well as insider threats.

from at least some retailers comments that chip&pin wasn't appropriate for internet transactions ... it might be inferred that chip&pin does session-like (as opposed to transaction) authentication ... regardless of whether it is SDA or DDA (possibly making it vulnerable to some of the end-point threats, mitm threats, and/or insider threats considered by the x9a10 financial standard working group).

UK Detects Chip-And-PIN Security Flaw
http://www.cardtechnology.com/article.html?id=20060606I2K75YSX

using the x9.59 transaction authentication paradigm, i had started on the aads chip strawman.
http://www.garlic.com/~lynn/x959.html#aads

at the NISSC conference in 98, i had quiped that I was going to take a mil-spec security token, cost reduce it by two orders of magnitude while increasing its security. from a chip&pin standpoint this met having a chip doing (transaction) "DDA" at higher integrity than the chip&pin DDA chip ... but at lower cost than the chip&pin SDA chip. The aads chip strawman also needed to be able to do x9.59 transaction authentication within iso14443 contactless power profile and within the transit industry turnstyle timing requirements.

tandem and atalla sponsored an x9.59/aads chip conference in jan. 1999
http://www.garlic.com/~lynn/aepay3.htm#riskm

later that spring, one of the aads conference participants demonstrated aads strawman chip in their booth at the spring pc/world conference in nyc doing a variety of financial and non-financial transactions; including a AADS RADIUS implementation
http://www.garlic.com/~lynn/subpubkey.html#radius
recent posting mentioning RADIUS
http://www.garlic.com/~lynn/aadsm23.htm#52 Status of opportunistic encryption

a number of aads strawman chips were also demonstrated in dec. 1999 at the world-wide retail banking show in miami, authenticating a variety of different kinds of financial and non-financial transactions.

i gave a presentation on assurance at the 2001 intel developer's forum (in the tpm track).
http://www.garlic.com/~lynn/index.html#presentation

I happened to quip during the presentation that it was nice to see that the TPM chip design had started to look more and more like the aads chip strawman over the previous year or so. the guy leading the TPM chip effort was in the front row and quiped back that it was because i didn't have a committee of 200 people helping me with my design.

AADS Postings and Posting Index, next, previous - home