Misc AADS & X9.59 Discussions

AADS Postings and Posting Index,
next,
previous, - home

Crypto to defend chip IP: snake oil or good idea?
Crypto to defend chip IP: snake oil or good idea?
Crypto to defend chip IP: snake oil or good idea?
Crypto to defend chip IP: snake oil or good idea?
Crypto to defend chip IP: snake oil or good idea?
Crypto to defend chip IP: snake oil or good idea?
Crypto to defend chip IP: snake oil or good idea?
Crypto to defend chip IP: snake oil or good idea?
smart cards with displays - at last!
DDA cards may address the UK Chip&Pin woes
Crypto to defend chip IP: snake oil or good idea?
And another cloning tale
Sarbanes-Oxley is what you get when you don't do FC
Sarbanes-Oxley is what you get when you don't do FC
Sarbanes-Oxley is what you get when you don't do FC
Sarbanes-Oxley is what you get when you don't do FC
Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts
Hamiltonian path as protection against DOS
Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts
Hamiltonian path as protection against DOS
Identity v. anonymity -- that is not the question
Identity v. anonymity -- that is not the question
Hamiltonian path as protection against DOS
Introducing the new HavenCo location
DDA cards may address the UK Chip&Pin woes
RSA SecurID SID800 Token vulnerable by design
Fraudwatch - how much a Brit costs, how to be a 419-er, Sarbanes-Oxley rises as fraud rises, the real Piracy
A note on vendor reaction speed to the e=3 problem
WESII - Programme - Economics of Securing the Information Infrastructure
Threatwatch - sigint by Hezbollah, nyms by torture units, closed source weaponry
On-card displays
On-card displays
On-card displays
Mozilla moves on security
Mozilla moves on security
signing all outbound email
signing all outbound email
How the Classical Scholars dropped security from the canon of Computer Science
How the Classical Scholars dropped security from the canon of Computer Science
How the Classical Scholars dropped security from the canon of Computer Science
Why security training is really important (and it ain't anything to do with security!)
Why security training is really important (and it ain't anything to do with security!)
Why security training is really important (and it ain't anything to do with security!)
Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
TPM & disk crypto
hashes on restricted domains: random functions or permutations?
Flaw exploited in RFID-enabled passports

Crypto to defend chip IP: snake oil or good idea?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Crypto to defend chip IP: snake oil or good idea?
Date: Thu, 27 Jul 2006 15:10:27 -0600
To: Perry E. Metzger <perry@xxxxxxxx>
CC: cryptography@xxxxxxxx

a related article (that also mentions certicom crypto):

How Secure Is That Device? As device software joins the larger world, security becomes ever more vital
http://dso.com/news/showArticle.jhtml?articleID=191501076

and some general comments in another thread
https://www.garlic.com/~lynn/2006o.html#2 the more things change, the more things stay the same

Crypto to defend chip IP: snake oil or good idea?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Crypto to defend chip IP: snake oil or good idea?
Date: Thu, 27 Jul 2006 20:53:26 -0600
To: tls@xxxxxxxx
CC: cryptography@xxxxxxxx

Thor Lancelot Simon wrote:
So, you sign the public key the chip generated, and inject the _signed_ key back into the chip, then package and ship it. This is how the SDK for IBM's crypto processors determines that it is talking to the genuine IBM product. It is a good idea, and it also leaves the chip set up for you with a preloaded master secret (its private key) for encrypting other keys for reuse in insecure environments, which is really handy.

But do we really think that general-purpose CPUs or DSPs are going to be packaged in the kind of enclosure IBM uses to protect the private keys inside its cryptographic modules?

... long post warning :) ...

that is basically a certificate-based process .... i.e. a recognized certification authority is signing the exported public key and injecting it back into the chip ... as a form of digital certificate.

this allows that some relying party ... that has a copy of the appropriate certification authority's public key to validate the device's digital certificate in an offline manner.

the approach i described was not the offline pki-based offline scenario but the certificate-less flavor ... the "relying party" accepts the public key from the device (and validates some digital signature produced by the device) and contacts the authoritative agency managing/hosting the fab's manifest. the authoritative agency then returns whether it is an original chip (rather than possibly a counterfeit / copy chip) and possibly also the integrity characteristics of the particular chip.

in any case, can you say parameterised risk management ?)

with respect to the "kind of enclosure IBM uses to protect the private keys inside the cryptographic modules" is that the integrity characteristics of any specific kind of chip is likely to be proportional to the vulnerabilities, threats, risks and purposes that the chip is used for. the high level of integrity for the ibm crypto unit's private key isn't directly related to the cost of the unit and/or whether it is a counterfeit unit ... it is much more related to various anticipated uses that the ibm crypto unit will be applied.

say a 10-50 cent security chip that has been evaluated to EAL5-high .... maybe even less expensive chips ... see discussion here
https://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK chip&Pin woes

... the integrity and protection of the private key is likely going to proportional to the purposes for which the chip will be used.

Part of the least expensive process ... is that other than the 20k-40k additional circuits ... the actual processing, processing steps, and processing time can done in such a way that there is absolutely no different from what they are doing today ... the initial power-on/test to validate a working chip (before it has been sliced and diced from the wafer) is the same exact step taking the same exact amount of time. the exporting of the test fields indicating a valid working chip as part of power-on/test ... is not changed ... other than there are a few more bits that represent the exported public key. the storage and maintenance in the fab chip manifest is exactly the same.

There is no incremental cost and no incremental processing ... other than the chip real estate for additional 20k-40k circuits.

If you treat it as a real security chip (the kind that goes into smartcards and hardware token) ... it eliminates the significant post-fab security handling (prior to finished delivery), in part to assure that counterfeit / copy chips haven't been introduced into the stream .... with no increase in vulnerability and threat.

So finally it comes down to later wanting to check whether you have a counterfeit / copy chip. The current scenario would be to read out the static data serial number and have that looked up in the fab's chip manifest. however serial number static data is vulnerable to things like skimming and replay attacks. So in the basic operation ... for effectively zero incremental cost ... you effectively get a dynamic data serial number authentication for looking up in the fab's chip manifest (as opposed to a simple static data serial number).

For nearly all uses of such a basic chip configuration, the cost of attacking the private key (in such a eal5-high evaluated chip) is much more than any likely benefit ... and is bracketed by being able to flag the chip serial and public key in the fab's chip manifest.

As an attack purely for the purposes of selling 50 cent copy chips ... each chip attack is going to cost enormously more than expected fraud revenue.

So you have to be expecting something other than a revenue from selling copy chips .... to mount such an attack, you would have to be expecting to be able to make use of the private key for some significantly larger benefit than selling a copy chip.

If you are talking about an attack on the private key ... for purpose other than selling a copy chip ... then you are into security proportional to risk ... i.e. having a variety of chips with integrity proportional to risks of their expected use ... some expected uses far above an EAL5-high evaluation ... maybe an EAL10 :) or EAL25 :) evaluation?

So for extremely close to zero cost ... you can add straight private key and digital signature to any chip as countermeasure to counterfeit and copy chips. As a side-effect ... it may possible to also use the digital signing capability of the embedded circuits to represent something you have authentication. However, the utilization of any such side-effect should be evaluated from the standpoint of the integrity of the chips private key environment and whether it is proportional to the risks associated with such expected application uses.

now when i was talking about this with some government types ... within the context of parameterised risk management ... i.e. the integrity of the chip and the associated private key integrity could be dynamically evaluated to see whether that it satisfied the requirements for the purposes it would be applied ... they commented that this area was totally missed in the work on x.509v3 digital certificates. they commented that if i were to develop an integrity level grading system (for a real-time, online parameterised risk management operation being able to dynamically take into account chip integrity ... including that the chip integrity may have degraded since it had been originally manufactured ... i.e. advances/changes in attack technology/knowledge may increased the chip vulnerability and lowered its integrity) ... then they would see that x.509v3 digital certificates were extended to allow specifying a static flavor of chip integrity level.

the basic process was that private key, digital signatures and public key could be added to existing chips at absolutely ZERO additional cost (other than the chip real-estate for 20k-40k additional circuits) as a countermeasure to copy chips (where the existing mechanism involves lookup using static serial number) ... aka countermeasure to copy chips. additional uses of such a private key and digital signature capability has to be evaluated the basic integrity level of the chip (& private key) against the risks associated with the target uses.

Some simple armoring of the private key comes with the design of the basic 20k-40k additional core (i.e. in many respects, the additional circuits operate as a separate computer core and nothing is directly available to the primary processor). That level of integrity may, in fact, be sufficient for a large number of applications.

so ... instead of having a lookup parameterised risk management system (as originally described) ... the integrity level stuff might indeed be retrofitted to stale, static x.509v3 certificates. in the ibm scenario ... the crypto unit would have an evaluated integrity level ... the public key is exported ... some sort of digital certificate is created with the crypto unit's public key and the crypto unit's integrity level ... and the result is digitally signed ... by some sort of certification authority .... and the certificate is injected back into the crypto unit. future users of the crypto unit can not only extract the digital certificate to validate it is an "original" crypto unit (as opposed to possibly a counterfeit or copy unit) ... and also have the integrity of the crypto unit at the time it was manufactured (for a moment ignoring that the integrity level of the crypto unit may degrade over time as technology advances) ... and evaluate whether the certified integrity level is sufficient for the uses for which it will be applied.

in the lookup parameterised risk management ... there is absolutely no change in current day standard fab chip processing ... the whole thing is submerged into processes that already occur. I think i was quoted something like a couple pennies per chip per second of additional processing. For the fundamental process, I had incentive ... to incorporate the key-gen and public key export into the existing fab chip processing so there was absolutely no increase in elapsed time of initial chip power-on/test.

NOTE, there is a basic premise here that parameterised risk management doesn't require that there can be one and only one integrity level that has to be met by all devices for all purposes .... it can assume that the required integrity level need only be sufficient to the purposes for which it will be applied. If it is only going to be used to raise the barrier for copy chip vulnerabilities for chips that are priced at tens of cents to tens of dollars ... you might choose one level of private key armoring. The level of private key armoring might be increased if you start talking about copy chip countermeasures for chips that cost hundreds or thousands of dollars.

The risk/threat landscape can also be considerably different if you are doing dynamic, online, real-time lookup or if you depending on a stale, static, offline digital certificate paradigm.

Another dynamic might be if such a design was incorporated into a variation of RFID chips where the RFID chip is then incorporated into a pill bottle worth hundreds of dollars and targeted as countermeasure to counterfeit/copy drug vulnerability (i.e. one of the issues in the original 40k circuit design from the late 90s was extremely low power requirements to work in contactless, radio frequency deployments)

as aside, the patents referenced in the original post (are assigned and we have NO interest)
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadssummary.htm

covered both digital certificate modes of operation and certificate-less operation.

some recent posts mentioning contactless/proximity and/or power/rf design considerations for the original aads chip strawman:
https://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes

misc. past posts mentioning parameterised risk management
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo2 QC Bio-info leak?
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo3 QC Bio-info leak?
https://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
https://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
https://www.garlic.com/~lynn/aepay3.htm#x959risk1 Risk Management in AA / draft X9.59
https://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment standard issue
https://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech9 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech10 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
https://www.garlic.com/~lynn/aadsm12.htm#17 Overcoming the potential downside of TCPA
https://www.garlic.com/~lynn/aadsm19.htm#15 Loss Expectancy in NPV calculations
https://www.garlic.com/~lynn/aadsm19.htm#44 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#8 simple (&secure??) PW-based web login (was Re: Another entry in the internet security hall of shame....)
https://www.garlic.com/~lynn/aadsm23.htm#1 RSA Adaptive Authentication
https://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
https://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
https://www.garlic.com/~lynn/2000.html#46 question about PKI...
https://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2001.html#73 how old are you guys
https://www.garlic.com/~lynn/2003j.html#33 A Dark Day
https://www.garlic.com/~lynn/2003p.html#26 Sun researchers: Computers do bad math ;)
https://www.garlic.com/~lynn/2004h.html#38
build-robots-which-can-automate-testing dept
https://www.garlic.com/~lynn/2005k.html#23 More on garbage
https://www.garlic.com/~lynn/2006g.html#40 Why are smart cards so dumb?

Crypto to defend chip IP: snake oil or good idea?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Crypto to defend chip IP: snake oil or good idea?
Date: Fri, 28 Jul 2006 12:16:59 -0600
To: tls@xxxxxxxx
CC: cryptography@xxxxxxxx

Crypto to defend chip IP: snake oil or good idea?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Crypto to defend chip IP: snake oil or good idea?
Date: Fri, 28 Jul 2006 12:22:23 -0600
To: tls@xxxxxxxx
CC: cryptography@xxxxxxxx

Crypto to defend chip IP: snake oil or good idea?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Crypto to defend chip IP: snake oil or good idea?
Date: Fri, 28 Jul 2006 15:52:55 -0600
To: tls@xxxxxxxx
CC: cryptography@xxxxxxxx

Thor Lancelot Simon wrote:
I don't get it. How is there "no increase in vulnerability and threat" if a manufacturer of counterfeit / copy chips can simply read the already generated private key out of a legitimate chip (because it's not protected by a tamperproof module, and the "significant post-fab security handling" has been eliminated) and make as many chips with that private key as he may care to?

Why should I believe it's any harder to steal the private key than to steal a "static serial number"?

so maybe we can look at another kind of static serial number vulnerability ... besides it will be nominally directly accessible by general programming and/or transmitted (neither of which would require capturing with physical intrusive methods).

so for more drift ... given another example of issues with static data authentication operations is that static serial numbers are normally considered particularly secret ... and partially as a result ... they tend to have a fairly regular pattern ... frequently even sequential. there is high probability that having captured a single static serial number ... you could possibly correctly guess another million or so static serial numbers w/o a lot of additional effort. This enables the possibly trivial initial effort to capture the first serial number to be further amortized over an additional million static serial numbers ... in effect, in the same effort it has taken to steal a single static serial number ... a million static serial numbers have effectively been stolen.

So even if you have a scenario where the effort to steal a single static serial number is exactly the same as the effort to steal a private key (because the chips containing them will never divulge and/or export either ... which is actually a false assumption, but just for argument sake assume it to be true) ... then we can still claim that when the effort has been made to steal a single static serial number ... that effort could then be amortized over a million static serial numbers ... while you are still stuck with only a single private key. the equation then is whether "identical effort" divided by one is the same as "identical effort" divided by a million.

so we could look at it from an additional analogy
https://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea?

and yet again another anlogy/example similar to static serial numbers tends to be account numbers. one of the static account number vulnerabilities in the 60s were their regular structure. attackers would use the regular structure nature of account numbers to conjure up bogus account numbers from which counterfeit magstripe payment cards were created. this would frequently be successful for performing fraudulent transactions.

eventually the payment card industry came up with a sort of secure hash that was written to magstripe along with the account number. basically it was a bank/bin "secret" mashed with the account number. the association network collected a table of all the bank/bin "secrets" and could check the secure hash on an account transaction against the computed value for the account (for instance, if they were going to be doing standin authorization).

you then started to see bogus reading of the magstripe (static data) by attackers ... who then would use the recorded information to create a counterfeit replica.

in the mid-90s, there was chip&pin effort as countermeasure to the bogus reading of magstripes. there was nothing that could be swiped and read ... so it prevented attackers from creating counterfeit cards from bogus reads.

the only problem was that sometime in the 80s, you started to also see attackers recording valid transactions ... they didn't actually need physical access to the card ... they just needed to be able to record valid transactions ... and since it was static data ... it could be readily used for replay attacks using counterfeit magstripe cards.

the chip&pin deployments in the late 90s thru recently would have the chip present a digital certificate as its authentication. It didn't do any actual public key operations ... it just presented the certificate. This was called static data authentication. The problem was that the technology used for skimming/recording valid (magstripe) transactions frequently worked equally well recording static data chip&pin transactions (the attackers didn't require any physical access ... they just skimmed/recorded valid transactions, in fact they could record tens of thousands of transactions enabling them to build tens of thousands of counterfeit cards).

Now since it was purely static data authentication, the attackers found that they could take a counterfeit chip and install the skimmed/recorded certificate ... and the chip would now pass as valid. In the late 90s, this got the label yes cards ... old yes card reference:
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

the reason for the yes card label was that the "chip&pin" effort, in addition to converting from less secure magstripe to a more secure chip ... also added requirement that the person enter their pin. the terminal would pass the pin to (an authenticated) chip and wait for the chip to answer yes or no as to whether the pin was correct. Of course, the counterfeit yes cards were programmed to always answer YES regardless of what was passed.

The other was since the chip was so much more secure than the magstripe ... and also more expensive ... infrastructure costs could be saved by offering to do offline (rather than online) transactions. after the chip had been authenticated and indicated the correct pin was entered ... the terminal could then ask the chip if it should do an offline transaction (rather than online) ... and then because it wasn't checking with the account ... it also had to ask the chip if the transaction was within the account credit limit. Of course a counterfeit yes card was programmed to always answer YES to these questions also

as an aside, it should be noted that none of this was an actual attack on the chip ... it was an attack on the terminals and the static data authentication paradigm.

as an aside in this same time-frame the x9a10 financial standard working group had been given the requirement to presenve the integrity of the financial infrastructure for all retail payments. the result was the x9.59 financial standard for all retail payments
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

previous posts on this subject:
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#53 Case Study: Thunderbird's brittle security as proof of Iang's 3rd Hypothesis in secure design: there is only one mode, and it's secure
https://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea?

and just for the fun of it, past posts discussing the yes card
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
https://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
https://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
https://www.garlic.com/~lynn/aadsm18.htm#20 RPOW - Reusable Proofs of Work
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
https://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
https://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
https://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#0 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#21 Use of TPM chip for RNG?
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#29 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#43 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
https://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram
https://www.garlic.com/~lynn/2004j.html#39 Methods of payment
https://www.garlic.com/~lynn/2004j.html#44 Methods of payment
https://www.garlic.com/~lynn/2005u.html#13 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006k.html#0 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006l.html#27 Google Architecture
https://www.garlic.com/~lynn/2006l.html#32 Google Architecture
https://www.garlic.com/~lynn/2006l.html#33 Google Architecture

Crypto to defend chip IP: snake oil or good idea?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Crypto to defend chip IP: snake oil or good idea?
Date: Fri, 28 Jul 2006 18:46:54 -0600
To: tls@xxxxxxxx
CC: cryptography@xxxxxxxx

Thor Lancelot Simon wrote:
The simple, cost-effective solution, then, would seem to be to generate "static serial numbers" like cipher keys -- with sufficient randomness and length that their sequence cannot be predicted. I still do not see the advantage (except to Certicom, who would doubtless like to charge a bunch of money for their "20-40k gate crypto code") of using asymmetric cryptography in this application.

which effectively gets you the same as the secure hash scenario for the static account number scenario ... example immediately following the million static serial numbers in the same post:
https://www.garlic.com/~lynn/aadsm25.htm#4

which is countermeasure to attackers taking advantage of regular pattern.

however, if the static serial number is ever used for any purpose ... it then has to be exposed ... since it is static ... it then is subject to skimming, evesdropping, etc ... and then used in replay attacks, i.e. previous post
https://www.garlic.com/~lynn/aadsm25.htm#4

the only equivalent of static serial number to private key is if it is never exposed ... which effectively implies that it is never used, i.e. previous post
https://www.garlic.com/~lynn/aadsm25.htm#4

for years the standard security response has been that the best security is to lock it away and never use it and/or provide access.

if it is ever used for any purpose ... then it can be exposed all over the place ... in manner similar to static account numbers (even with the static secure hash) described in the same posting as the million account number scenario, i.e. previous post
https://www.garlic.com/~lynn/aadsm25.htm#4

so is the issue really with asymmetric key cryptography technology done in custom circuit design ... or is the issue with certicom??

btw, the 40k circuit core design that i referred to done in late 99 and early 2000 had no certicom content ... even the ecc was done w/o any certicom content.

Crypto to defend chip IP: snake oil or good idea?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Crypto to defend chip IP: snake oil or good idea?
Date: Fri, 28 Jul 2006 22:36:58 -0600
To: tls@xxxxxxxx
CC: cryptography@xxxxxxxx, Lynn Wheeler <lynn@xxxxxxxx>

Thor Lancelot Simon wrote:
As Perry said, chip fabs have plenty of diagnostic equipment that would extract an RSA private key every bit as easily as it would extract a private serial number, which means that the additional cost of 20-40 gates, plus IP licensing, plus... for a cryptographic engine is strictly wasted. I am a happy Certicom customer but I certainly wouldn't buy _this_ product from them.

fab has plenty of equipment ... at some point there needs to be a little trust ... the fab could also create copy chips with back doors that would enable attackers with the appropriate knowledge to extract all private keys from all manufactured chips .... w/o even requiring diagnostic equipment. there are audit processes that are designed to preclude both the backdoor design scenario as well as the private key extraction scenario.

my claim is that whether it is 20-40 gates or 20k-40k gates, both can be equivalently trivial ... or at least unable to differentiate the difference if you are talking about 100 million circuit chip.

my assertion is that there is incremental benefit of asymmetric key operation over straight static serial number. in the scenario where the asymmetric key operation is being used as countermeasure to copy chips ... there may even be incentive for the fab to not compromise their own chips.

there are also some interesting processes in fabs around the poweron/test situation to narrow the vulnerability of possible private key extraction (after the key may be generated) ... unless you are talking about physical invasive techniques that damage the chip (negating the purpose of having/using digital signature from the private key for proof of a valid, undamaged, working chip).

my assertion is that the cost of the additional gates can be more than offset by improving/eliminating other chip processing related processes ... resulting in a net economic benefit .... this is improved by aggresive cost reduction of the additional gates .... so it might need to save no more than dollar or two in other chip post-fab handling for a net economic benefit (i.e. it may be able to accomplish asymmetric key circuits for pennies)

you seem to be asserting that the complexity of asymmetric key circuits would require savings on the order of possibly hundreds of dollars (per chip) to show any net economic benefit.

somewhat related is that there are lots of current chip activity where they have an excess of circuit real estate that they are somewhat desperately looking for applications for. if they can front load some incremental purpose that uses the excess circuits ... the design costs are front loaded and may then be amortized across hundreds of millions of chips ... effectively driving the actual circuit related cost per chip (for the incremental feature) to zero. if it doesn't actually increase any post fab per chip processing cost ... and can decrease any post fab per chip processing cost ... then it actually takes extremely little savings to show a net economic infrastructure benefit.

things have changed from the days when they would be desperately trying to cram the minimum necessary into the available chip real estate, to know, where they sometimes have more chip real estate than they know what to do with

in my scenario ... it takes relatively trivial copy chip countermeasure incremental benefit to justify fabs adding the feature to their chips.

recent posts in this thread:
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#53 Case Study: Thunderbird's brittle security as proof of Iang's 3rd Hypothesis in secure design: there is only one mode, and it's secure
https://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#5 Crypto to defend chip IP: snake oil or good idea?

Crypto to defend chip IP: snake oil or good idea?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Crypto to defend chip IP: snake oil or good idea?
Date: Sun, 30 Jul 2006 09:33:20 -0600
To: cryptography@xxxxxxxx

from long ago and far away ....

Date: Wed, 17Nov1999 14:13:42 -0800
From: wheeler
Subject: Re: a smartcard of a different color

The USB chip is starting to come up higher on peoples' radar ... bunch of discussion was kicked off by this posting.

the NACHA announcement talks about not absolutely requiring chip for the signing ... however that means that they can't tell whether it was chipped signed or not.

Within the AADS infrastructure, it can be a stand-alone AADS chip (possibly in as few as 20,000 circuits compared to several hundred thousand to tens of million circuits for the smartbrick chips).

Not only can the AADS chip definition be used for ubiquitous authentication purposes ... but it is trivial to include such a small chip in almost any kind of package ... either as a separate chip (say in a card, USB housing or corner of a PDA or cellphone) ... or in the corner of a more complex chip (pentium, k7, strongarm, etc).

In principle, it is technical possible for the same AADS function/chip to be used for digital signing (and authenticating) multiple X9.59 debit&credit accounts, ISP internet login, corporate intranet login, webserver access, and business process access.

... snip ... top of post, old email index

i.e. origin for:
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snoke or or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snoke or or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snoke or or good idea?

above refers to same implementation as both a countermeasure to copy chips as well as basis for person-centric operation.

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

reference to NACHA AADS trials
https://www.garlic.com/~lynn/x959.html#aadsnacha

previous post discussing person-centric operation
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?

smart cards with displays - at last!

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 30, 2006 05:07 PM
Subject: smart cards with displays - at last!
Blog: Financial Cryptography

re:
http://financialcryptography.com/mt/archives/000792.html

in theory, people with cellphones and/or pdas could use their own pin entry device ... and the cellphone/pda could have proximity, near field, bluetooth, &/or wifi ... with point-of-sale (and/or some server).

note that all sorts of things are subject to mitm-attacks ... this mentions possibility of mitm-attacks on terminals (potentially even with dda cards):
https://www.garlic.com/~lynn/2006o.html#16 Gen 2 EPC Protocol Approved as ISO 18000-6C
https://www.garlic.com/~lynn/2006o.html#17 Gen 2 EPC Protocol Approved as ISO 18000-6C

... however there possibly are also MITM-attacks against cards even with class 4 secured reader (aka possibly even overlays similar to what has been used with ATM-machines, counterfeit/compromised operations). this is somewhat related to the finread stuff:
https://www.garlic.com/~lynn/subintegrity.html#finread

in the case of finread, the terminal is supposedly yours and it is used for your own protection where potentially your own PC (that the finread is attached to) might be compromised (an isolated security boundary supposedly out of reach of common PC compromises)

in the case of a class 4 secured terminal ... there is potential of something like a MITM-attack terminal/overlay between you and the real terminal.

misc. past postings mentioning MITM-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

recent near field article:

Near Field Communication Technology Turns Cell Phones into "Debit Cards"
http://www.dailytech.com/article.aspx?newsid=1856

DDA cards may address the UK Chip&Pin woes

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 3, 2006 09:40 AM
Subject: DDA cards may address the UK Chip&Pin woes
Blog: Financial Cryptography

Hackers clone e-passports
http://www.wired.com/news/technology/0,71521-0.html

sounds somewhat akin to the yes card clones of sda chip&pin that started to show up in the 90s.
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#43 DDA cards may address the UK Chip&Pin woes

related thread:
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV
along with:
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defind chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#8 smard cards with displays

x-reference:
https://financialcryptography.com/mt/archives/000770.html

Crypto to defend chip IP: snake oil or good idea?

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Crypto to defend chip IP: snake oil or good idea?
Date: Sat, 05 Aug 2006 06:04:08 -0600
To: Marcos el Ruptor <ruptor@xxxxxxxx>
CC: cryptography@xxxxxxxx

Marcos el Ruptor wrote:
You can use cryptography to protect IP and to prevent cloning of microchips even if they get reverse-engineered, but the cipher would have to possess special properties similar to those of VEST ciphers (see
http://www.ecrypt.eu.org/stream/vestp2.html ), like support family keying to make every ASIC chip implement different secret but secure logic, etc. eBeam, lasers and other technologies are available for that. ECC and other standard ciphers can't possibly do that.

so one could claim that the difference is along the lines of trade secrets vis-a-vis patents &/or copyrights .... at least for the 20,000 circuit scenario i was talking about
https://www.garlic.com/~lynn/aadsm25.htm#7

i.e. using authentication to help differentiate "originals" from copy chips (as opposed to hiding, privacy, confidentiality)
https://www.garlic.com/~lynn/aadsm24.htm#49

and other parts of the thread
https://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#5 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP: snake oil or good idea?

as an aside, i noticed that a lot of recent spam about copy this and copy that ... actually claims it to be "replicas" (watches, etc). it could be difficult to tell the difference from a work-a-like copy chip ... and an original ... especially if it happens to be embedded in something (and hiding the implementation doesn't directly prevent a work-a-like)

authentication raises the bar on telling an original vis-a-vis a counterfeit/copy ... something like the holograms and other brand stuff they put on various physical products ... or the stuff they put into money. it doesn't actually try and hide the details of the original (just making it harder for a counterfeit to pass as an original)

for a little drift, recent post on long ago and far away court case involving theft of trade secrets
https://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security

the above also drifted into the subject of security proportional to risk ... unrelated post
https://www.garlic.com/~lynn/2001h.html#61

for even more drift ... collected past posts about being involved in project as an undergraduate that reverse engineered interface and built a clone mainframe control unit ... and article that was written blaming us for the resulting several billion dollar/annum market (PCM, plug compatible manufacturer)
https://www.garlic.com/~lynn/submain.html#360pcm

of course, the response/countermeasure to PCM was FS ... lots of past FS posts
https://www.garlic.com/~lynn/submain.html#futuresys
a specific post discussing FS countermeasure to PCM
https://www.garlic.com/~lynn/2000f.html#16 FS - IBM Future System

the other analogy is electronic commerce that has attempted to use privacy/confidentiality to hide transaction details as countermeasure to fraudulent transactions
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

compared to x9.59 financial standard using transaction strong authentication
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

to preserve the integrity of the finanical infrastructure for all retail transactions (requirement given the x9a10 financial standard working group for the standard)... w/o needing privacy/confidentiality (hiding) as countermeasure to fraudulent transactions

and further drift ... about possibility of various kinds of attacks (replay attacks, mitm-attacks) w/o strong authentication or where authentication is used for a device w/o having strong authentication on an actual transaction
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II

And another cloning tale

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: And another cloning tale
Date: Tue, 08 Aug 2006 07:22:12 -0600
CC: cryptography@xxxxxxxx

and if you happened to miss this thread on chip&pin cloning
https://www.garlic.com/~lynn/aadsm25.htm#9 DDA cards may address the UK chip&pin woes

there is always the current e-passport news (aka form of static data skimming and replay attack which at least traces back to magstripe copying)
Researcher warns of security problem in electronic passports
http://seattlepi.nwsource.com/local/6420AP_NV_Computer_Security.html
Researchers: E-passports pose security risk
http://news.zdnet.com/2100-1009_22-6102608.html
Researchers: E-passports pose security risk
http://news.com.com/2100-7349_3-6102608.html?part=rss&tag=6102608&subj=news
Researchers: E-passports pose security risk
http://news.com.com/Researchers+E-passports+pose+security+risk/2100-7349_3-6102608.html?tag=nefd.top
Researcher: E-passports easy to clone
http://www.securityfocus.com/brief/272
Researchers: E-passports pose security risk
http://news.com.com/Researchers+E-passports+pose+security+risk/2100-7349_3-6102608.html
Researcher warns of security problem in electronic passports
http://www.networkworld.com/news/2004/112204ecbriefs.html
Expert Warns on E-Passport Security
http://www.redorbit.com/news/technology/603572/expert_warns_on_epassport_security/index.html
Expert Issues Warning About E-Passports
http://abcnews.go.com/Technology/wireStory?id=2278740
German hackers clone RFID e-passports
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=20856
Expert: E-passports vulnerable
http://www.azstarnet.com/news/140980
Expert Issues Warning About E-Passports
http://www.forbes.com/entrepreneurs/feeds/ap/2006/08/06/ap2929834.html
Hackers crack new biometric passports
http://politics.guardian.co.uk/homeaffairs/story/0,,1838754,00.html
Expert warns on e-passport security
http://www.msnbc.msn.com/id/14218149/
RFID e-passports hacking and terrorism risk says experts
http://www.itwire.com.au/content/view/5199/53/
Electronic passports vulnerable, expert says
http://www.ctv.ca/servlet/ArticleNews/story/CTVNews/20060806/electronic_passport_060806/20060806?hub=SciTech
RFID passports vulnerable to hackers, security expert says
http://www.theglobeandmail.com/servlet/story/RTGAM.20060806.welecpass0806/BNStory/Technology/home
German Security Consultant Clones E-Passports
http://www.allheadlinenews.com/articles/7004421125
E Passports Susceptible To Cloning
http://www.securitypronews.com/news/securitynews/spn-45-20060803EPassportsSusceptibleToCloning.html
Leader: Of course passport security is too weak
http://software.silicon.com/security/0,39024655,39161216,00.htm
Researcher warns of security problem in electronic passports
http://news.bostonherald.com/national/view.bg?articleid=151637
Expert warns on e-passport security
http://msnbc.msn.com/id/14218149/
German hackers clone RFID e-passports
http://www.desktops.engadget.com/2006/08/03/german-hackers-clone-rfid-e-passports/
German Expert: RFID Chips In E-Passports Can Be Cloned
http://www.playfuls.com/news_03822_German_Expert_RFID_Chips_In_E_Passports_Can_Be_Cloned_.html
E-passports.. a neverending story!

http://www.zone-h.org/content/view/13965/31/
Expert issues warning about e-passports
http://www.businessweek.com/ap/financialnews/D8JAN2680.htm?sub=apn_tech_down&chan=tc

Sarbanes-Oxley is what you get when you don't do FC

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 9, 2006 12:30 PM
Subject: Sarbanes-Oxley is what you get when you don't do FC
Blog: Financial Cryptography

re:
https://financialcryptography.com/mt/archives/000797.html

there is slightly different point that i made in a EU conference last fall regarding the sox audit process ... aka audit has been used to check corporate books for inconsistency (typically independent physical books) ... as potential indication of wrong doing.

i asserted that with books moving to IT technology ... the IT technology could be programmed to generate consistent books.

SOX then asks for information in ever increasing detail. This can aid business people in understanding their business ... if they don't otherwise have the understanding.

However, from the standpoint of catching things wrong ... the assertion is that IT technology could be leveraged to generate single source, consistent numbers to any level of detail (just increasing the level of reporting detail won't necessarily create independent sources that can be examined for inconsistencies).

at a conference recently in june, somebody commented that for a small to medium size company the sox bill is currently running $800k.

the issue isn't so much that it is a matter of more regulation or less regulation ... again, yet, still ... it is a matter of looking at what is the threat model and whether the selected countermeasure(s) are effective for that threat model.

past posts on the subject:
https://www.garlic.com/~lynn/aadsm19.htm#10 Security as a "Consumer Choice" model or as a sales (SANS) model?
https://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm23.htm#10 PGP "master keys"
https://www.garlic.com/~lynn/aadsm24.htm#35 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#36 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#39 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#40 Interesting bit of a quote
https://www.garlic.com/~lynn/2006.html#12a sox, auditing, finding improprieties
https://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
https://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley
https://www.garlic.com/~lynn/2006j.html#28 Password Complexity
https://www.garlic.com/~lynn/2006n.html#32 The System/360 Model 20 Wasn't As Bad As All That

Sarbanes-Oxley is what you get when you don't do FC

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 10, 2006 06:47 PM
Subject: Sarbanes-Oxley is what you get when you don't do FC
Blog: Financial Cryptography

the other way of looking at is that the insiders generate the books, the auditors check the books for mistakes or inaccuracies.

in iso9000 type scenario ... they are looking for whether you have gotten it correct.

the sox scneario is more looking for whether somebody has gotten it wrong, possibly purposefully wrong. when there were independent records from independent sources ... the auditors could look for inconsistencies.

the possiblility exists if all the records are being generated by a single IT system ... there is no longer independent sources allowing auditors cross-checking, looking for inconsistencies ... possibly making it extremely difficult to identify purposeful incorrect records.

increasing the amount of data examined doesn't directly address the issue of having independent sources to check for inconsistencies (of possibly purposeful incorrect records)

ref:
https://www.garlic.com/~lynn/aadsm25.htm#12 Sarbanes-Oxley is what you get when you don't do FC

the breach issue can be looked at differently. the issue here frequently involves financial account numbers. the problem is on one hand, financial account numbers need to be available in hundreds of business processes for correct functioning. At the same time, exposure of the financial account number may be sufficient to perform fraudulent transactions.

this can create diametricly opposing objectives ... on one hand, the account number has to be generally available for the correct functioning of business processes and on the other hand the account number has to be kept confidential and never exposed.

this is somewhat my old risk proportional to security item
https://www.garlic.com/~lynn/2001h.html#61

the other part of it is the work in the x9a10 financial standard working group from the mid-90s that had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the result was the x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

part of the x9.59 standard eliminates just having knowledge of the account number as a threat for fraudulent transactions (eliminating the diametricly opposing objectives for treatment of account numbers; readily available and never available).

this is part of my periodic postings about the existing infastructure and even if the planet was buried miles deep in crypto ... it still couldn't prevent account number leakage
https://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
https://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
https://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
https://www.garlic.com/~lynn/2001.html#45 what is UART?
https://www.garlic.com/~lynn/2003k.html#11 humor in source code
https://www.garlic.com/~lynn/2003k.html#37 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2005k.html#26 More on garbage
https://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006h.html#15 Security
https://www.garlic.com/~lynn/2006h.html#26 Security
https://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop

Sarbanes-Oxley is what you get when you don't do FC

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 11, 2006 09:18 AM
Subject: Sarbanes-Oxley is what you get when you don't do FC
Blog: Financial Cryptography

a couple news things from yesterday

Strategic Innovation << Dealing With The Metadata Mess >>
http://www.bizintelligencepipeline.com/showArticle.jhtml?articleId=191801849

Finance company finds way though Basel II maze
http://www.silicon.com/financialservices/0,3800010322,39161291,00.htm

... and ...

Basel II: Revised international capital framework
http://www.bis.org/publ/bcbsca.htm

ref:
https://www.garlic.com/~lynn/aadsm25.htm#13

Basel II then is somewhat more like iso9000 than sox ... i.e. it isn't trying to identify corporate misdeeds.

it is more trying to assess how well a financial institution is doing its business ... which then results in "risk adjusted capital" ... based on the risk assessed by Basel II, the financial institution has to set aside capital to cover the evaluated risk.

basel II is a lot of quantative measurements of the risks for a financial institution. it is more along the lines of parameterised risk management ... mentioned in these posts
https://www.garlic.com/~lynn/aadsm25.htm#1
https://www.garlic.com/~lynn/aadsm25.htm#2

the original basel II draft had a whole new section titled qualitative measurements ... which was mostly dropped in subsequent iterations. qualitative measurements was somewhat more along the lines could you describe all your end-to-end business processes ... such that the board of directors knew what all the business was (and possibly was there a risk factor if it didn't)

Then there is the issue of metadata and data quality ... do you understand your data, what it means, and is it accurate and correct (as opposed to possibly purposefully incorrect). we've been periodically involved in such metadata and data quality stuff with our knowledge base stuff
https://www.garlic.com/~lynn/index.html

Sarbanes-Oxley is what you get when you don't do FC

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 11, 2006 10:48 AM
Subject: Sarbanes-Oxley is what you get when you don't do FC
Blog: Financial Cryptography

oh, and a sox related news item from today:

Compliance Newsflashes: SEC Eases Up on SOX for Small and Foreign Companies
http://www.financetech.com/news/showArticle.jhtml?articleID=205604551

... and for a little drift on the basel II topic
https://www.garlic.com/~lynn/aadsm25.htm#14

inactive funds held in (risk adjusted) capital reserves can represent a significant hit on institution's bottom line. as a result, there can be significant incentive for a financial institution to do as well as possible in basel ii evaluation.

for some other drift on capital reserves ... the following is a long winded discussion on the thread between risk management and information security
https://www.garlic.com/~lynn/aepay3.htm#riskm

but has some discussion about the sequence of events that followed the capital reserve requirement for savings and loans being cut in half in the 80s.

Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 16, 2006 02:23 PM
Subject: Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts
Blog: Financial Cryptography

ref:
https://financialcryptography.com/mt/archives/000586.html

mention of IBM SDA chip&pin deployment for Safeway UK in 1997
https://www.garlic.com/~lynn/2006l.html#33

not too long later the cloned yes cards appeared; a reference to counterfeit sda chip&pin yes card from 2002 (which also mentions that detailed information for building counterfeit yes card was readily available from the internet)
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

then SDA chip&pin in 2006, vulnerable to the same yes card exploits from the 90s. a recent summary of some of the issues
https://www.garlic.com/~lynn/2006o.html#40

subsequent news mentioned that replacement DDA chip&pin cards would be countermeasure to the 90s counterfeit cloned SDA chip&pin yes cards. however, if it is still purely card something you have authentication, ... see discussion
https://www.garlic.com/~lynn/2006o.html#40

the infrastructure may still be vulnerabile to mitm-attacks (pairing a counterfeit yes card with a valid card).
https://www.garlic.com/~lynn/subintegrity.html#mitm

in the SDA chip&pin dating back to the mid-90s, supposedly there is multi-factor authentication, the something you have card (based on the card being able to present static authentication data) and the something you know PIN entry.

for a "counterfeit" yes card, it involves copying the static authentication data from a valid card (possibly just evesdropping a valid transaction, maybe with a counterfeit/compromised terminal) ... which then becomes a type of replay-attack. the yes card presents the (cloned) static authentication data to the terminal and then after the PIN is entered (something you know authentication), the terminal asks the yes card if it is the correct PIN. Of course, yes cards (in part where they got their label), always answer YES.

The assumption about multi-factor authentication being more secure is based on assumption that the different factors are subject to independent vulnerabilities and threats ... i.e. PIN as a form of something you know authentication is a countermeasure to lost/stolen (something you have authentication) card.

However, in the yes card scenario, the infrastructure is vulnerable because the successful attacker doesn't actually need to know a correct PIN ... since terminal just relies on the card as to whether the PIN is correct or not. All the successful attacker needs to do is load cloned static authentication data into a yes card ... or possibly (in the case of a DDA chip&pin card), pair an appropriately programmed yes card with a valid card for a MITM-attack.

back in the mid-90s, when the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments ... most forms of both replay-attacks as well as MITM-attacks were among the things considered for the x9.59 financial standard (in part because the same exact standard needed to work, at least, in both point-of-sale as well as over the internet).
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

for various reasons, many replay-attacks and mitm-attacks that are well documented for the internet evironment are also possible in the point-of-sale environment ... but possibly not so clearly evident.

Hamiltonian path as protection against DOS

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Hamiltonian path as protection against DOS.
Date: Wed, 16 Aug 2006 13:45:46 -0600
To: michaelslists@xxxxxxxx
CC: Bill Stewart <bill.stewart@xxxxxxxx>,
"James A. Donald" <jamesd@xxxxxxxx>,  cryptography@xxxxxxxx

mikeiscool wrote:
Could this sort of system be something that is implemented way before a HTTP connection even starts?

Say, implemented by OS vendors or API vendors of sockets. That is to say, when you open a socket connection for the first time, for certain protocols, you need to pay this fee. The socket lib would be adjusted to do it, and then you are good to go.

It would mean that other services get the benefit of protection. But is there legimate need to connect to many, or one, host many thousands of times? I'd guess there is.

Take the discussed handshakes. Could something be incorporated there?

Maybe there could be a new low level protocol, kind of like SSL, but less cost involved ... then you could tell your server to operate in that mode only...

it can also be considered from the standpoint of a lot of SSL is transaction oriented.

you start with reliable TCP session support ... which has a minimum of 7-packet exchange. then you encapsulate all the HTTPS hand-shaking ... which eventually possibly reduces to doing a transaction packet exchange (as opposed to really requiring full session semantics).

in the late 80s, there was work on reliable XTP, a transaction oriented protocol that supported reliable internet with a minimum of 3-packet exchange (disclaimer, my wife and I were on the XTP technical advisory board)
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

so a lot of the SSL stuff around ssl server certificates is validating that the server you think you are talking to is actually the server you are talking to .... by checking the domain name from the URL that you supposedly typed in against the domain name in the ssl server certificate. a big vulnerability was created when a lot of the merchant servers ... that were the original prime target for ssl server certificates ... backed way from using SSL for the whole web experience and reduced it to just the payment transaction. the problem then was that the supposedly typed in URL came from a button provided by the server ... and not actually typed in by the client. the ssl server process then became checking the domain name in the URL provided by the server against the domain name in the certificate provided by the server (totally subverting original security assumptions). lots of past collected posts mentioning ssl server certificate infrastructure
https://www.garlic.com/~lynn/subpubkey.html#sslcert

So the next part was that somebody applies for a SSL server certificate .... which basically involves the certification authority checking the applicant provided information against what is on file with the domain name infrastructure. there was some integrity issues with this information being hijacked/changed ... so the certification authority industry was backing a proposal that domain name owners register a public key (with the domain name infrastructure) along with the other information. Then all future communication would be digitally signed (as countermeasure to various hijacking vulnerabilities).

the issue then is that certification authorities can now request that ssl server certificate applications also be digitally signed. the certification authorities, then can validate the digital signature with the public key onfile with domain name infrastructure (turning a time-consuming, error-prone, and expensive identification process into a much simpler, less-expensive and efficient authentication process)

note that the existing infrastructure has the trust root with the information on file with the domain name infrastructure (that has to be cross-checked for identification purposes). the change to registering a public key retains the domain name infrastructure as the trust root (but changing from an expensive identification operation to a much simpler authentication operation).

so a real SSL simplification, when the client contacts the domain name infrastructure to do the domain name to ip-address translation, the domain name infrastructure can piggy-back the public key and any necessary ssl options on the ip-address reply.

the client then composes a XTP transaction (has minimum 3-packet exchange for reliable operation) that has an "SSL" packet structure. the client generates a random transaction key, encrypts the communication with the random generated key and encrypts the random key with the server's public key ... and sends it off the encrypted random key and the encrypted communication.

for purely transaction operation, there is minimum (XTP) 3-packet exchange between client and server. however, if more data is involved, then as many packets as necessary are transmitted. I've suggested this design numerous times in the past.

as an aside, i've pointed out before that in the mid-90s that as webserver activity was increasing ... a lot of platforms experienced severe throughput degradation with HTTP transaction protocol use of TCP. Most platforms had a highly inefficient session close implementation around checking of the FINWAIT list ... the assumption was that most session activity had relatively infrequent session open/close activity. The HTTP transaction activity violated those TCP activity assumptions ... and for a period of time you found platforms spending over 95percent of their processor utilization dealing with the FINWAIT list.

Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 16, 2006 08:22 PM
Subject: Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts
Blog: Financial Cryptography

re:
https://www.garlic.com/~lynn/aadsm25.htm#16 Fraudwatch - Chip&Pin one-side story

recent item somewhat related to earlier comments

Banks seek new fraud solutions
http://www.vnunet.com/computing/news/2162444/banks-seek-fraud-solutions

Hamiltonian path as protection against DOS

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Hamiltonian path as protection against DOS.
Date: Thu, 17 Aug 2006 16:28:33 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: michaelslists@xxxxxxxx, Bill Stewart <bill.stewart@xxxxxxxx>,
cryptography@xxxxxxxx

James A. Donald wrote:
This is obviously the right way to do it - the current system has security and checking boundaries in the wrong place, as well as being unnecessarily verbose.

Yet the plan never went anywhere. What happened?

There is a gap between communications that are highly efficient with TCP, and communications that are highly efficient with UDP. Brief transactions (which must be reliable and two way, but are brief, are not efficient with either one.

Indeed, ideally we would have one protocol that rapidly starts to approximate TCP behavior with communications that for which TCP is good (transferring large files) and that approximates UDP with communications for which UDP is good.

ref:
https://www.garlic.com/~lynn/aadsm25.htm#17 Hamiltonian path as protection against DOS

so much of postings at
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

talks about attempting to standardize xtp as HSP (high-speed protocol) in ansi x3s3.3 (and iso chartered organization) ... which was under mandate that no standardization work could be done on networking protocol that was in violation of the OSI model. turns out xtp/hsp violated OSI model in at least three different ways.

xtp implementation was an adjunct to the tcp/ip (typically kernel) protocol stack.

I've often commented that both SSL and VPN were successful because they added security layer w/o requiring changes to the (kernel) tcp/ip protocol stack.

A person that we had worked with quite a bit introduced something (that since become to be called VPN) in gateway working group at the '94 san jose IETF meeting. my view was that it caused quite a bit of consternation in the ipsec crowd ... which were working on implementation that had hits to the underlying tcp/ip stack. VPN got a lot a lot of immediate uptake because it added security w/o requiring hits to the protocol stack in the end-nodes. The ipsec crowd somewhat reconciled VPN by starting to call it lightweight ipsec ... and some number of others then started calling (regular) ipsec, heavyweight ipsec.

original (lightweight ipsec) vpn resulted in some peculiarities .... being a countermeasure to internet anarchy by being a boundary router between corporate intranets tunneled thru the internet ... w/o requiring changes to the end-points. part of the issue was that some of the router vendors had sufficient extra processing capacity to do the necessary vpn crypto and some didn't. so two months after the san jose ietf meeting ... you saw some router vendors announcing VPN "products" that were actually just add-on of traditional hardware link encryptor boxes.

so i've frequently claimed that ssl got market traction in much the same way that vpn got market traction ... by providing a solution that avoided hits to the (kernel) tcp/ip protocol stacks (modulo some really emergency server fixes at some high-end websites to handle the finwait list handling problem).

requiring coordinated (most frequently kernel) tcp/ip protocol stack upgrades for all (or majority of the) machines in the world, is a uptake inhibitor. ssl wasn't necessarily the optimal networking solution ... but it did have the minimum impact on existing deployed infrastructure.

in any case, some of the xtp features are starting to appear in some of the real-time streaming extensions ... like one of my favorites ... rate-based pacing (which i was forced to implement in high-speed backbones in the mid-80s)

many of the online xtp resources have since gone 404 ... however there still are a few around
http://usuario.cicese.mx/~aarmenta/frames/redes/xtp/biblio.html
http://www.pcmag.com/encyclopedia_term/0,2542,t=XTP&i=55105,00.asp
http://www.ccii.co.za/products/xtp.html

HTTP1.1 attempted to amortize multiple HTTP interactions across a single tcp session (attempting to mitigate the overhead of reliable session protocol for something that was frequently very transaction oriented). again w/o requiring hits to the underlying protocol stack.

Identity v. anonymity -- that is not the question

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 22, 2006 11:10 AM
Subject: Identity v. anonymity -- that is not the question
Blog: Financial Cryptography

re:
https://financialcryptography.com/mt/archives/000805.html

in the mid-90s the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the resulting protocol was x9.59 which we claimed was privacy agnostic
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

a transaction had account number and was digitally signed ... and provided for end-to-end authentication and integrity. to the extent there might be a binding between an account number and an identity ... was outside the x9.59 protocol.

part of this was the realization by numerous institutions in the mid-90s that the x.509 "identity" certificates represented enormous privacy and liability exposures. this led to some of the abortions that attempted to preserve the x.509 infrastructures but eliminating most identity features ... at the time, periodically referred to as relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

and we were repeatedly able to show that such relying-party-only certificates were redundant and superfluous.

the theme about end-to-end authentication and integrity was also somewhat the subject of the naked transaction threads here:
https://financialcryptography.com/mt/archives/000744.html
https://financialcryptography.com/mt/archives/000745.html
https://financialcryptography.com/mt/archives/000747.html
https://financialcryptography.com/mt/archives/000749.html

a lot of SSL use has been hiding transactions during internet transit ... not so much for privacy purposes but for integrity purposes and fraud prevention. however, that left the transactions exposed at thousands of other points. this is somewhat my old post about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

for instance, lots of the data breaches in the news involves attackers being able to use the exposed information for fraudulent transactions. Neither SSL nor x9.59 addresses such data breaches. however, x9.59 eliminates the possibility that the attackers can use the acquired information for generating fraudulent transactions (account fraud)

from the perspective of the x9a10 working group effort ... a lot of the other activities from the period had extremely poorly defined threat models and even less linkage between their possible efforts and exactly how such efforts represented specific countermeasures for specific threats.

recent posting in another fora related to some SSL use:
https://www.garlic.com/~lynn/aadsm25.htm#17 Hamiltonian path as protection against DOS
https://www.garlic.com/~lynn/aadsm25.htm#19 Hamiltonian path as protection against DOS

Identity v. anonymity -- that is not the question

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 22, 2006 12:32 PM
Subject: Identity v. anonymity -- that is not the question
Blog: Financial Cryptography

for other drift ... we had been called in to help word smith the cal. state electronic signature legislation (and later federal electronic signature legislation)
https://www.garlic.com/~lynn/subpubkey.html#signature

one of the participating industry organizations was also involved in various privacy regulation and legislation efforts. they had done a survey regarding the primary driving factors behind privacy regulations and legislation and found them to be

identity theft
denial-of-service (by institutions to individuals)

more recently there has been efforts by various organizations to further clarify identity theft ... into

account fraud (using information to perform fraudulent transactions against existing accounts)
identity fraud (using information to open new accounts in the name of the victim)

a large portion of the data breaches involve the account fraud flavor of identity theft.

as mention in the previous comment
https://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question

x9.59 doesn't have countermeasure for data breaches ... again the old posting about security proportional to risk:
https://www.garlic.com/~lynn/2001h.html#61

however x9.59 does have countermeasure against account fraud ... i.e. being able to use the information from data breaches (or other mechanisms) as part of performing fraudulent transactions against existing accounts.

and for other privacy drift ... i was co-author for the financial industry x9.99 PIA privacy standard ... and as part of that did work on a merged privacy taxonomy and glossary
https://www.garlic.com/~lynn/index.html#glosnote

which includes sources from EUDPD, FTC, GLBA, HIPAA, OECD and OMB.

Hamiltonian path as protection against DOS

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Hamiltonian path as protection against DOS.
Date: Tue, 22 Aug 2006 21:26:09 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx

James A. Donald wrote:
Why do we need wide consensus to add a new protocol on top of IP?

I was under the impression that the internet talks IP, not TCP and UDP. If this is the case, then any client server or peer to peer software could whip up its own protocol on top of IP, standards being so desirable that everyone should have one of their own.

So what goes wrong when some software does its own thing with IP?

re:
https://www.garlic.com/~lynn/aadsm25.htm#17
https://www.garlic.com/~lynn/aadsm25.htm#19

so most programmers were doing socket programming ... basically transport level ... which basically gave you tcp. the issue for doing other implementations is somewhat like the issue of getting them to program in other than C language ... similar but different set of postings about significantly larger frequency of buffer problems occuring in C language implementations
https://www.garlic.com/~lynn/subintegrity.html#overflow

i've told the story about having sign-off on the payment gateway side of the protocol ... and enforcing various requirements. however, didn't have similar authority on the client implementation side ... and even had problems even getting client simple multiple A-record support implemented.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

i'm tempted to quote the saying about in theory there is no difference between theory and practice, but in practice there is.

xtp did other stuff besides rate-based pacing and minimum 3-packet exchange for reliable communication. one of the things that a lot of effort went into was zero-buffer copy ... attempting to pipeline/stream network avoiding any sort of buffer copy ... recent posting mentioning zero buffer copy
https://www.garlic.com/~lynn/2006o.html#64

misc. past posts mentioning early client/server startup wanting to do payments on their server, the payment gateway ... and issues with the client side getting them to do stuff like multiple a-record support
https://www.garlic.com/~lynn/96.html#34 Mainframes & Unix
https://www.garlic.com/~lynn/99.html#16 Old Computers
https://www.garlic.com/~lynn/99.html#158 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#159 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
https://www.garlic.com/~lynn/2002.html#23 Buffer overflow
https://www.garlic.com/~lynn/2002.html#32 Buffer overflow
https://www.garlic.com/~lynn/2002.html#34 Buffer overflow
https://www.garlic.com/~lynn/2003.html#30 Round robin IS NOT load balancing (?)
https://www.garlic.com/~lynn/2003.html#33 Round robin IS NOT load balancing (?)
https://www.garlic.com/~lynn/2003c.html#8 Network separation using host w/multiple network interfaces
https://www.garlic.com/~lynn/2003c.html#12 Network separation using host w/multiple network interfaces
https://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces
https://www.garlic.com/~lynn/2003c.html#25 Network separation using host w/multiple network interfaces
https://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment
https://www.garlic.com/~lynn/2004k.html#32 Frontiernet insists on being my firewall
https://www.garlic.com/~lynn/2004o.html#53 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2005f.html#55 What is the "name" of a system?
https://www.garlic.com/~lynn/2005g.html#21 Protocol stack - disadvantages (revision)
https://www.garlic.com/~lynn/2005n.html#5 Wildcard SSL Certificates
https://www.garlic.com/~lynn/2005n.html#34 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2005o.html#24 is a computer like an airport?
https://www.garlic.com/~lynn/2005r.html#32 How does the internet really look like ?
https://www.garlic.com/~lynn/2005r.html#39 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006j.html#15 30 hop limit

Introducing the new HavenCo location

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: September 6, 2006 10:47 PM
Subject: Introducing the new HavenCo location
Blog: Financial Cryptography

re:
https://financialcryptography.com/mt/archives/000808.html

since you asked the question :), having lived with the site of mt. umunhum for many years ...

could be seen from all over the valley, the radar is gone, but the support building can still be seen.
http://www.pbase.com/bryan_murahashi/image/55468656

This radar site was in operation from 1958-1970; there was a huge 85-ton AN/FPS-24 radar installation located at the radar site. The building remains still standing at the 3,486 foot summit of Mt. Umunhum are a relic of the Cold War.

more views
http://www.radomes.org/museum/recent/AlmadenAFSCA.html

a tale of some early stanford sail computer "teething" problems
http://www-db.stanford.edu/pub/voy/museum/pictures/AIlab/SailFarewell.html
above gone 404, but is also at:
http://infolab.stanford.edu/pub/voy/museum/pictures/AIlab/SailFarewell.html

I got proper air conditioning a short time later, but unfortunately developed a bad case of hiccups that struck regularly at 12 second intervals. My assistants spent a number of days trying to find the cause of this mysterious malady without success. As luck would have it, somebody brought a portable radio into my room one day and noticed that it was emitting a "Bzz" at regular intervals -- in fact, at the same moment that I hicced. Further investigation revealed that the high-powered air defense radar atop Mt. Umunhum, about 20 miles away, was causing some of my transistors to act as radio receivers. We solved this problem by improving my grounding.

... snip ...

couldn't find any pictures of mt umunhum with the radar still in place ... but here are some pages with an/fps-24 including one with dome.
http://www.radomes.org/museum/equip/fps-24.html

another an/fps-24 page
http://www.fas.org/nuke/guide/usa/airdef/an-fps-24.htm

trying to find some comparison to x-band dome
http://www.fas.org/spp/starwars/program/gbr.htm

the relative size of the buildings and by comparison the dome, would seem to indicate the an/fps-24 dome was larger than the x-band dome?

DDA cards may address the UK Chip&Pin woes

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: September 9, 2006 12:31 PM
Subject: DDA cards may address the UK Chip&Pin woes
Blog: Financial Cryptography

re:
https://financialcryptography.com/mt/archives/000776.html

somewhere in a study for aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads
in the early 99 time-frame ... there was test about doing ecdsa signature in well under a second using contactless chip (drawing power from the air), less expensive than sda token and higher integrity than dda token ... and work on a custom circuit design that would do it under .1 second drawing much less power

slightly related set of posts
https://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP: snake oil or good idea?

and for other topic drift;

New PCI DSS is out
http://www.emergentchaos.com/archives/2006/09/new_pci_dss_is_out.html
Credit Card Giants Modify Security Specs
http://www.darkreading.com/document.asp?doc_id=103292

** one more time, can you say security proportional to risk?
https://www.garlic.com/~lynn/2001h.html#61

Credit card companies forge security alliance
http://www.tgdaily.com/2006/09/08/credit_card_security/
Credit card companies forge security alliance
http://www.silicon.com/financialservices/0,3800010322,39162214,00.htm
Credit Card Brokers Launch Security Effort
http://www.extremetech.com/article2/0,1697,2013829,00.asp

Laptop Larceny, First Possible Case of Fraud
http://www.firstcoastnews.com/news/local/news-article.aspx?storyid=64422
Second Life Database Suffers Huge Security Breach
http://www.playfeed.com/index.php/playfeed/article/second-life-database-suffers-huge-security-breach-09081814/
Theft of 900 bank customer files prompts e-privacy primer
http://www.cbc.ca/story/news/national/2006/09/08/laptop-privacy.html
At a Loss Over Data Loss
http://www.spot-on.com/archives/spinney/2006/09/at_a_loss_over_data_loss.html

** can we bury the planet under miles of cryptography?
https://www.garlic.com/~lynn/2006k.html#2
https://www.garlic.com/~lynn/2006k.html#17
https://www.garlic.com/~lynn/2006k.html#18
https://www.garlic.com/~lynn/2006k.html#19

Ponemon Institute Study Shows Lack of Accountability, Resources at Root of U.S. Corporate Data Loss Problem
http://www.portauthoritytech.com/news/releases/pr_082806_ponemon.html
Privacy Trust Studies
http://www.ponemon.org/privacytrust.html
Information Security Policy
http://www.ponemon.org/policy.html
Statement From Scott & Scott LLP In Response to Ponemon Institute's Data Breach Prevention Findings
http://biz.yahoo.com/bw/060908/20060908005296.html?.v=1
Rising Security Threats Require Tougher Notification Laws, But At What Price?
http://www.processor.com/editorial/article.asp?article=articles%2Fp2836%2F30p36%2F30p36.asp&guid=&searchtype=&WordList=&bJumpTo=True

other posts in this thread:
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#29 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#37 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#43 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#50 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm25.htm#9 DDA cards may address the UK Chip&Pin woes

RSA SecurID SID800 Token vulnerable by design

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: RSA SecurID SID800 Token vulnerable by design
Date: Sat, 09 Sep 2006 14:12:51 -0600
To: Lance James <lancej@xxxxxxxx>
CC: cryptography@xxxxxxxx, hadmut@xxxxxxxx

Lance James wrote:
Agreed, and since my research is focused on online banking I can see yours and my point, either way, SecurID should not be the only concept for dependence.

as i've mentioned serveral times, in the mid-90s, the x9a10 financial standards working group was given the task of preserving the integrity of the financial infrastructure for all retail payments. the result was x9.59 standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

which specified (end-to-end) authenticated transaction (and a business rule that account numbers used in x9.59 transactions could not be used in non-authenticated transactions) ... recent, related post:
https://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK Chip&Pin woes

part of the issue was with the actual transactions being signed and running end-to-end ... and account numbers no longer vulnerable to "naked" exploits ... it was no longer necessary to hide the account number (as countermeasure to prevent fraudulent replay attack transactions).
https://www.garlic.com/~lynn/subintegrity.html#harvest

the issue then became end-point attacks; either the originating end-point or the authorizing end-point. most infrastructure have had the authorizing end-points pretty well armored for some time. that primarily leaves vulnerabilities at the originating end-point.

part of the EU finread terminal work was to close off some of the originating end-point vulnerabilities.
https://www.garlic.com/~lynn/subintegrity.html#finread

basically an independent, secure token terminal with its own display and key-entry. the transactions is forwarded from the end-point to the finread terminal ... the finread terminal displays a summary of the transaction details ... and passes it to the token for digital signing. any pin-entry (for two-factor authentication ... token something you have and pin-entry something you know) is performed at the finread terminal (minimizing any pin evesdropping and associated pin replay attack exploits). misc. collected posts mentioning 3-factor authentication paradigm:
https://www.garlic.com/~lynn/subintegrity.html#3factor

while session encryption is useful for confidentiality and privacy of the operations ... a lot of existing session encryption is primarily because existing transactions don't have end-to-end armored authentication ... leaving various pieces of information involved in the actual transaction naked and vulnerable to various kinds of threats like replay attacks; skimming/harvesting information for fraudulent transactions (requiring no independent authentication)
https://www.garlic.com/~lynn/subintegrity.html#harvest

the x9.59 standards approach was to provide end-to-end armoring of the actual transactions ... eliminating numerous kinds of replay vulnerabilities and some of the man-in-the-middle attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

... independent of any possible use of authentication for session purposes

note that while it isn't part of the x9.59 standard ... the standard was carefully crafted such that end-point environments like the EU finread would be allowed to also sign transactions.

the issue is that the responsible authorization end-point frequently will be doing risk assessment (especially involving financial transactions). it is easy to see that an EU finread terminal provides a much higher integrity digital signing environment than many personal computers (for instance, virus software that logs the entered pin and replays it to a connected hardware token w/o the person's knowledge) ... for the authorizing end-point, it can be useful to have some knowledge about the transaction originating integrity when doing risk assessment.

Fraudwatch - how much a Brit costs, how to be a 419-er, Sarbanes-Oxley rises as fraud rises, the real Piracy

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: September 10, 2006 03:43 PM
Subject: Fraudwatch - how much a Brit costs, how to be a 419-er, Sarbanes-Oxley rises as fraud rises, the real Piracy
Blog: Financial Cryptography

re:
https://financialcryptography.com/mt/archives/000800.html

recent item:
Commission Proposes Radical Change To Data Protection Rules For ISPs And Telcos
http://www.mondaq.com/article.asp?articleid=42460&hotopic=1

from above:
Contained in a "Staff Working Document"1 the Commission states (without giving its source) that "the market has so far failed to address security problems to the satisfaction of users". To remedy this problem it proposes to require providers of electronic communications networks and services to:

• notify the relevant national regulator of any breach of security that led to the loss of personal data and/or to interruptions in the continuity of service supply. The regulator would then be able to inform the general public of the breach if they considered that it was in the public interest to do so; and

• notify their customers of any breach of security leading to the loss, modification or destruction of, or unauthorised access to, customer personal data. ... snip ...

for other topic drift ... i was co-author of the x9.99 financial standard ... and as part of that work put together a merged privacy taxonomy and glossary ... drawing on multiple sources (eu-dpd, glba, hipaa, etc)
https://www.garlic.com/~lynn/index.html#glosnote

A note on vendor reaction speed to the e=3 problem

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A note on vendor reaction speed to the e=3 problem
Date: Sat, 16 Sep 2006 13:57:06 -0600
To: cryptography@xxxxxxxx

Taral wrote:
*That* is the Right Way To Do It. If there are variable parts (like hash OID, perhaps), parse them out, then regenerate the signature data and compare it byte-for-byte with the decrypted signature. Anything you don't understand/control that might be variable (e.g. options) is eliminated by this process.

FSTC originally created FSML for digitally signed xml encoded data ... which was then donated to w3c and became part of xml digital signature specification.

the issue for FSTC was "e-checks" ... where originator took fields from ACH transaction ... encoding them in XML, digitally signed the XML encoding, and then appended the signature to the original ACH transaction. the recipient received the ACH transaction ... duplicated the original XML encoding process, computed the hash ... and then compared it to the decoded signature (from the ACH transaction append field).

the original issue for FSML was that XML didn't have a bit-deterministic encoding process ... which could result in the originator and the recipient getting different results doing XML encoding of ACH transaction fields.

X9.59 financial transaction specified something similar
https://www.garlic.com/~lynn/x959.html#x959

which allowed originator and recipient to perform deterministic encoding of standard financial transaction (in manner similar to FSTC e-check process) ... where the signature was carried in standard electronic transaction append field. the base standard specified ASN.1 encoding ... but the fully constituted x9.59 fields included a version field ... the purpose of which included being able to specify an x9.59 version that used XML encoding (rather than ASN.1 encoding).

the standard just specified all the fields and ordering for the encoding.

there were sample mappings between the fields in the standard and fields in various existing financial transactions. if x9.59 called for fields that weren't part of specific financial transaction ... then those fields needed to be carried in the transaction append/addenda, along with the digital signature (i.e. the digital signature was appended to standard transaction in unencoded format, it wasn't required that the encoded format being transmitted ... just that the encoded format could be reproduced in a deterministic manner).

old write-up giving correspondence between x9.59 fields and some fields from some common financial transaction formats (includes a proposed xml tagged encoding)
https://www.garlic.com/~lynn/8583flow.htm

part of the issue for the x9.59 standard was the requirement for a standard that preserved the integrity of the financial infrastructure for all retail payments (ALL, including point-of-sale).

A typical point-of-sale payment card transaction avgs. 60-80 bytes. By comparison, some of the PKI digital signature based financial specifications from the mid-90s had enormous payload bloat, resulting in message sizes of 4k-12k bytes (or more) ... aka increasing transaction payload size by two orders of magnitude (100 times).
https://www.garlic.com/~lynn/subpubkey.html#x959
https://www.garlic.com/~lynn/subpubkey.html#certless

WESII - Programme - Economics of Securing the Information Infrastructure

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: September 17, 2006 01:28 PM
Subject: WESII - Programme - Economics of Securing the Information Infrastructure
Blog: Financial Cryptography

re:
https://financialcryptography.com/mt/archives/000815.html

slightly related news article:

American National Standards Institute :: Internet Security Alliance and American National Standards Institute Announce New Collaboration for Improving Information Security
http://sev.prnewswire.com/computer-electronics/20060915/NYF02815092006-1.html

recent posts mentioning some of the efficiency issues related to armoring transactions with strong authentication as opposed to perpetually having to hide all the information.
https://www.garlic.com/~lynn/aadsm25.htm#25
https://www.garlic.com/~lynn/aadsm25.htm#27

i.e. is information security oriented towards preventing bad things ... or is it oriented towards hiding information as the only mechanism for preventing bad things?

old long winded post on the thread between risk management and information security
https://www.garlic.com/~lynn/aepay3.htm#riskm

and of course earlier entries on naked payments:
https://financialcryptography.com/mt/archives/000745.html
https://financialcryptography.com/mt/archives/000744.html
https://financialcryptography.com/mt/archives/000749.html

older news article

Bank workers biggest ID theft threat
http://deseretnews.com/dn/view/0,1249,600145529,00.html

and another old post: Study: ID theft usually an inside job
https://www.garlic.com/~lynn/aadsm17.htm#38

of course a lot of this predates current uptic in phishing ... where getting victim to divulge relatively trivial information like their account number ... can precipitate fraudulent transactions (again, another characteristic/feature of naked transactions).

(long winded) post discussing catch-22 for the pki domain name certification industry with regards to possible implications of DNSSEC deployment:
https://www.garlic.com/~lynn/2006f.html#33

collected posts mentioning using DNS for real-time public key distribution
https://www.garlic.com/~lynn/subpubkey.html#catch22

Threatwatch - sigint by Hezbollah, nyms by torture units, closed source weaponry

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: September 20, 2006 10:40 AM
Subject: Threatwatch - sigint by Hezbollah, nyms by torture units, closed source weaponry
Blog: Financial Cryptography

re:
https://financialcryptography.com/mt/archives/000678.html

In a related episode, Washington DC discovered around the same timeframe that there may be an issue with the Boeing 787, so they have asked Boeing to not hand over any military or secret related material to the Chinese. Whoops, too late, it turns out the wing is being manufactured in China ... for those who don't know, in avionics terms, the wing is the prize as it is the one component that limits and dominates everything else, design wise.

... snip ...

and John Boyd was responsible for a lot of modern plane design techniques ... and trading off various flight operational characteristics.

I've recently been scanning some of his old briefings from the early 80s and using them was background for my boyd URLs

misc. past postings mentioning boyd
https://www.garlic.com/~lynn/subboyd.html#boyd

misc. URLs from around the web mentioning boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2

On-card displays

Refed: **, - **

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: On-card displays
Date: Mon, 25 Sep 2006 21:19:02 -0600
To: Jeff.Hodges@xxxxxxxx
CC: cryptography@xxxxxxxx

Jeff.Hodges@xxxxxxxx wrote:
From: Ian Brown <I.Brown@xxxxxxxx>
Subject: On-card displays
To: ukcrypto@xxxxxxxx
Date: Wed, 20 Sep 2006 07:29:13 +0100

Via Bruce Schneier's blog, flexible displays that can sit on smartcards. So we finally have an output mechanism that means you don't have to trust smartcard terminal displays:
http://www.cr80news.com/library/2006/09/16/on-card-displays-become-reality-making-cards-more-secure/

So, when do we see the combined chip/fingerprint reader/display on a payment card :) Doesn't of course address the requirement that we want evidence (such as a signed paper receipt) that can later be adjudicated by a court with higher evidential standards than a bank statement that their systems work perfectly...

for a decade or so ... i've made comments that the increasingly powerful smartcards are obsolete because they are really pda(/cellphone) wannabes (after some of the gov. technology transfer legislation in the early 90s, we did some consulting for one of the gov. agencies on attempting to move some smartcard chip based technology into the commercial sector ... and we could already see it was rapidly becoming obsolete).

the smartcard target of portable computing device from 70s/80s required various kinds of iso standards because of the lack of appropriate portable input/output capability .... so there would be standardized, fixed input/output stations that could be used with the portable smartcards. that market niche for smartcards became obsolete with the appearance of pda/cellphone portable input/output capability sometime in the early to mid-90s.

possibly part of the problem was that there was significant investment in various kinds of smartcard technology during the 80s and 90s ... and when they became obsolete ... there was some amount of scurrying around attempting to obtain some/any return on the original investments ... even if it was only a few cents on the dollar.

they are now contending with various kinds of cellphone/pda payment delivery operations.

there is some paradigm discontinuity tho. there is a tradition grown up where the institutions issue the card (payment, identification, etc) ... to some extent smartcard activities are attempting to capitalize on that legacy momentum.

an individual's cellphone/pda tends to break that institutional centric issuing paradigm ... since it can involve an individual taking their cellphone/pda (that they already have) and registering it for various activities/transactions/identification ... aka another form of something you have authentication ... but it is possibly a personal device rather than an institution issued device.

so there are already various kinds of pda/cellphones with display, input capability ... and some of them even have their own biometric sensing capability.

the issue with "electronic signature" is demonstration of intent ... we got into that when we were asked to help word-smith some of the cal state (and later federal) electronic signature act. various past postings mentioning issue of establishing intent
https://www.garlic.com/~lynn/subpubkey.html#signature

On-card displays

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: On-card displays
Date: Mon, 25 Sep 2006 21:48:40 -0600
To: Steve Schear <s.schear@xxxxxxxx>
CC: Jeff.Hodges@xxxxxxxx,  cryptography@xxxxxxxx

Steve Schear wrote:
I have a Mondex card from years ago that used a separate reader with LCD.

we were asked to do the design/sizing/cost for mondex infrastructure in the us.

one of the things that turned up was much of the mondex infrastructure was based on float (initially essentially all going to mondex international) ... cards were almost incidental. somewhere along the way, mondex international even started offering to split the float with national organizations as an inducement to sign up.

somewhere along the way a group was also formed to try and map mondex to the internet ... which eventually morphed into IOTP.

at one point several EU central banks stated that the "stored value" operations (like mondex) would be allowed a grace period and allowed to keep the float (to help fund them getting their operation established), but after the grace period, they would start having to pay consumers the interest on unspent value (on deposit in the cards). at that point, the "float" income disappears.

misc. past posts that mention mondex
https://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop
https://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
https://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
https://www.garlic.com/~lynn/aadsm18.htm#42 Payment Application Programmers Interface (API) for IOTP
https://www.garlic.com/~lynn/aadsm20.htm#7 EMV
https://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm23.htm#23 Payment systems - the explosion of 1995 is happening in 2006
https://www.garlic.com/~lynn/2002e.html#14 EMV cards
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002g.html#53 Are you sure about MONDEX?
https://www.garlic.com/~lynn/2002g.html#54 Are you sure about MONDEX?
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2005i.html#10 Revoking the Root
https://www.garlic.com/~lynn/2005v.html#1 Is Mondex secure?

On-card displays

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: On-card displays
Date: Tue, 26 Sep 2006 09:19:37 -0600
To: cryptography@xxxxxxxx

and for a whole lot of drift with respect to smartcards being pda/cellphone wanabees

Storm building over RFID-enabled passports
http://www.networkworld.com/news/2006/121206-sun-solaris-getting-security-virtualization.html

from above:
The chip, which is embedded inside the cover of the passport, contains only a duplicate copy of the passport photograph and the printed data. The digital data is intended to prevent forgeries by allowing inspectors to compare the printed and digital data.

... snip ...

the article mentions that integrity of the electronic data is protected by a digital signature (preventing tampering and/or forgeries).

At some level, the digitally signed data can be considered a electronic credential that is extremely difficult to counterfeit.

posting with number of references about cloning (electronic) passport data
https://www.garlic.com/~lynn/aadsm25.htm#11 And another cloning tale

from three factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor

something you have
something you know
something you are

... frequently hardware tokens (chips) are implemented as something you have authentication (i.e. the chip supposedly contains some unique information ... which differentiates it from every other chip). some recent posts mentioning something you have authentication.
https://www.garlic.com/~lynn/aadsm25.htm#30 On-card displays
https://www.garlic.com/~lynn/aadsm25.htm#25 RSA SecurID SID800 Token vulnerable by design
https://www.garlic.com/~lynn/aadsm25.htm#16 Fraudwatch - Chip&PIN one-sided story

however, taking the passport chip data as an electronic credential, cloning the information doesn't (directly) represent a vulnerability ... since it is more analogous to digital certificates ... which are readily assumed to be widely distributable.

the passport chip data as an electronic credential containing a digital photograph ... and matching a person's face to the digital photograph then represents something you are authentication (as opposed to assuming the chip ...or even a cloned chip ... represents any sort of something you have authentication).

in theory, an electronic credential would be considered valid, regardless of any specific chip container that it might be carried in. one might then make the assertion, that a passport electronic credential could be carried in any device capable of reliably reproducing the correct bits.

going back to the issue raised in
https://www.garlic.com/~lynn/aadsm25.htm#30 On-card displays

that most smartcards/chips are really pda/cellphone wanabees ... one might suggest that you could then even carry your electronic credential/passport in your pda or cellphone ... as opposed to needing a separate physical device.

the issue that then is raised are there any significant privacy considerations similar to privacy issues raised with x.509 identity digital certificates from the early 90s (having large amounts of personal information in x.509 identity digital certificates widely distributed all over the place).

by the mid-90s, many institutions considered that the privacy and liability problems with x.509 identity digital certificates were so significant that they retrenched to "relaying-party-only" certificates. lots of past posts mentioning rpo-certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

these were digital certificates that effectively only contained some sort of database index or account number. the relying party then used the account number to retrieve the actual information of interest (w/o having to widely expose it in any way).

the analogy for an electronic passport infrastructure would be just needing to present the passport number. the actual credential data (and any photos or other information necessary for something you are authentication) is retrieved from secure online repository.

as repeatedly pointed out in the "RPO" digital certificate scenario ... it isn't even necessary to include the account/passport number in a digitally signed document ... since there is no information that needs integrity protection. the person just makes an assertion as to their correct account/passport number. the appropriate information is then retrieved from the online infrastructure and used for authentication (and whatever other required purposes). asserting the wrong account/passport number presumably retrieves information that fails to result in valid authentication.

needing (some certification authority) to digitally sign the passport/account number (in the RPO scenario) for any possible integrity purposes, is then redundant and superfluous (one of my oft repeated comments). misc. posts mentioning certificate-less mode of operation
https://www.garlic.com/~lynn/subpubkey.html#certless

note that this is in contrast to the yes card vulnerability, where the chip (static data) credential actually did represent purely something you have authentication
https://www.garlic.com/~lynn/subintegrity.html#yescard

Mozilla moves on security

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: September 28, 2006 12:07 PM
Subject: Mozilla moves on security
Blog: Financial Cryptography

re:
https://financialcryptography.com/mt/archives/000822.html

related to security proportional to risk ... old standby
https://www.garlic.com/~lynn/2001h.html#61

and one of the first places that I encounted the issue:
https://www.garlic.com/~lynn/2006q.html#36

however, a couple recent posts looking at the threat model aspect of security proportional to risk
https://www.garlic.com/~lynn/aadsm25.htm#32
https://www.garlic.com/~lynn/2006r.html#28

the original thread was can you trust rfid/contractless chips to not leak information. the threat model aspect is what kind of information might be leaked.

in the yes card vulnerability ... lots of past posts
https://www.garlic.com/~lynn/subintegrity.html#yescard

the information is used in something you have authentication operation ... i.e. cloning/copying information can be sufficient for performing fraudulent transactions.

in the passport scenario ... it is supposedly personal information that is part of something you are authentication. the photo still has to be matched against your face.

the leakage of personal information can still represent a privacy vulnerability ... but it depends on the type of information and the associated usage.

we had to looked at some of this when we were working on x9.99 financial industry privacy standard ... including reviewing eu-dpd, hipaa, and glba. during this work, i put together a merged privacy taxonomy and glossary
https://www.garlic.com/~lynn/privacy.htm

see notes at:
https://www.garlic.com/~lynn/index.html#glosnote

and the oft repeated past comment ... much of current financial transaction infrastructure is based on static data authentication ... and therefor is quite vulnerable to any sort of leakage;

from the security PAIN acronym

privacy (or sometimes CAIN and confidentiality)
authentication
integrity
non-repudiation

the existing financial transaction infrastructure tends to rely heavily on authentication that requires privacy/confidentiality (i.e. the information has to be kept hidden and never exposed).

x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

moved it from privacy/confidentiality requirement to an integrity requirement. the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. x9.59 changed the transaction paradigm from requiring the information to be hidden in order to have security to requiring integrity in order to have security (i.e. it isn't necessary to hide an x9.59 transaction in order to preserve the integrity of the financial infrastructure for all retail payments)

Mozilla moves on security

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: September 28, 2006 12:55 PM
Subject: Mozilla moves on security
Blog: Financial Cryptography

re:
https://www.garlic.com/~lynn/aadsm25.htm#33

oh and security proportional to risk just raised in real time in comp.arch regarding theft of trade secrets ... and comment that it may lead to eliminating (some amount of) dialup internet use for telecommuting

my reply/comments:
https://www.garlic.com/~lynn/2006r.html#29

we had looked at this issue some 25 years ago with regard to dail-up telecommuting. one of the issues found was that hotel PBXs are a major vulnerability ... almost anybody can get into them and install various kinds of evesdropping.

the result was the corporation built special encrypting dial-up modems ... that included stuff like session handshaking and session dynamic key exchange ... which was then mandated for all offsite (dial-up) connection into company facilities.

as i've mentioned in the past, the company's internal network was larger than the arpanet/internet from just about the beginning until possibly sometime mid-85.
https://www.garlic.com/~lynn/subnetwork.html#internalnet

and link encryptors were required on all network links that left corporate facilities. sometime in the mid-80s, it was also claimed that the internal network had over half of all link encryptors in the world.

misc. past posts mentioning the hotel pbx vulnerability:
https://www.garlic.com/~lynn/aadsm12.htm#4 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
https://www.garlic.com/~lynn/2003j.html#17 pbx security from 20 years ago
https://www.garlic.com/~lynn/2004g.html#34 network history
https://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
https://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2006p.html#35 Metroliner telephone article

signing all outbound email

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: signing all outbound email
Date: Sat, 30 Sep 2006 16:29:56 -0600
To: Jon Callas <jon@xxxxxxxx>
CC: Travis H. <solinym@xxxxxxxx>

Jon Callas wrote:
Take a look at DKIM (Domain Keys Identified Mail) which does precisely that. There is an IETF working group for it, and it is presently being deployed by people like Yahoo, Google, and others. There's support for it in SpamAssassin as well as a Sendmail milter.

recently published IETF RFC:

... from my IETF RFC index
https://www.garlic.com/~lynn/rfcietff.htm

4686 I
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM), Fenton J., 2006/09/26 (29pp) (.txt=70382) (Refs 1939, 2821, 2822, 3501, 4033) (was draft-ietf-dkim-threats-03.txt)

from the introduction:

The DomainKeys Identified Mail (DKIM) protocol is being specified by the IETF DKIM Working Group. The DKIM protocol defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the use of a given email address. Message recipients can verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain. This document addresses threats relative to two works in progress by the DKIM Working Group, the DKIM signature specification [DKIM-BASE] and DKIM Sender Signing Practices [DKIM-SSP].

... snip ...

can you say AADS?
https://www.garlic.com/~lynn/index.html#aads

and/or certificate-less:
https://www.garlic.com/~lynn/subpubkey.html#certless

signing all outbound email

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: signing all outbound email
Date: Sun, 01 Oct 2006 18:35:39 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: Jon Callas <jon@xxxxxxxx>, "Travis H." <solinym@xxxxxxxx>,
Cryptography <cryptography@xxxxxxxx>

James A. Donald wrote:
In order for this to actually be any use, the recipient needs to verify the signature and do something on the basis of that signature - presumably whitelist email that genuinely comes from well known domains.

Unfortunately, the MTA cannot reliably do something - if it drops unsigned mail that is fairly disastrous, and the MUA cannot reliably check signatures, since the MTA is apt to mess the signatures up.

re:
https://www.garlic.com/~lynn/aadsm25.htm#35 signing all outbound email

so what if an isp only signs email where the origin address is the same as the claimed email "from" address.

then email that claims to be from such an isp, that isn't signed, might assumed to be impersonation.

and any "abuse" reports to the isp ...where the email has been signed ... should at least trace back to the correct originating account.

ISPs could do ingress filtering where they only process incoming email from their customers ... where the origin address matches the email "from" address ... which would eliminate their customers from impersonating other addresses ... but doesn't preclude customers at non-participating ISPs from impersonating their customers.

ISPs could also start to quarentine unsigned email that claims to have originated from ISPs that are known to sign email.

it might be considered to be small step up from ssl domain name digital certificates ... where the browser checks that the domain name in the URL is the same as in the certificate. the issue in the ssl domain name scenario is some common use where the user has little or no awareness of the domain name in the URL .... so the fact that the actual domain name matches the domain name in the certificate may bring little additional benefit.

lots of past collected posts mentioning ssl domain name certificates ... some of the posts mentioning merchant comfort digital certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcert

How the Classical Scholars dropped security from the canon of Computer Science

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: October 5, 2006 02:17 PM
Subject: How the Classical Scholars dropped security from the canon of Computer Science
Blog: Financial Cryptography

re:
https://financialcryptography.com/mt/archives/000824.html

around the time we were doing some work on the original payment gateway (for what has since became to be called e-commerce)
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

I frequently commented that to take a standard, well-tested application and turn it into an industrial strength dataprocessing "service", typically required 4-10 times the original effort. as mentioned in the above references ... two of the people that we had worked with when we were doing our high-availability (ha/cmp) product ... were now responsible for the commerce server. old posting about an old ha/cmp meeting
https://www.garlic.com/~lynn/95.html#13

misc. past posts mentioning ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp

we have also made the statement that payment gateway could be considered the original SOA ... part of that is from coming up with 3-tier architecture in the 80s
https://www.garlic.com/~lynn/subnetwork.html#3tier

when we started ha/cmp we did a detailed failure mode analysis on tcp/ip protocol and code. some of the items we turned up ... showed up in attacks nearly 10 years later .... i.e. from the standpoint of doing industrial strength dataprocessing ... a failure mode analysis is a superset of some types of security treat analysis .... or you upgrade the term threat analysis to any type of problem ... not solely limited to stuff related to human attackers.

of course part of the history was having done a lot of work in the 60s & 70s on operating systems that were used for commercial time-sharing services
https://www.garlic.com/~lynn/submain.html#timeshare

where the implicit assumption was that the full community of users could have hostile intent with regard to each other ... compared to today where very few people take seriously that the default assumption that the standard operating environment is extremely hostile.

there used to be the old joke that computer science institutional memory is no more than five years. this somewhat goes along with the current idea that free software is something new ... as opposed to be the default in the 50s, 60s, and 70s. some amount of the change was gov. litigation and the resulting 23jun69 unbundling announcement that started trend charging for software ... some number of past posts about transition from free software to charge-for/licensed software
https://www.garlic.com/~lynn/submain.html#unbundle

some past posts mentioning identifying failure modes ... some of which didn't actually materialize (in attacks) to nearly ten years later:
https://www.garlic.com/~lynn/2004g.html#11 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#42 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
https://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2006e.html#11 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006i.html#6 The Pankian Metaphor

some number of past posts mentioning it taking 4-10 times the effort to turn a well-tested application into an industrial strength dataprocessing service
https://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
https://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
https://www.garlic.com/~lynn/2002n.html#11 Wanted: the SOUNDS of classic computing
https://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003j.html#15 A Dark Day
https://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
https://www.garlic.com/~lynn/2004b.html#8 Mars Rover Not Responding
https://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions
https://www.garlic.com/~lynn/2004k.html#20 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?
https://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions
https://www.garlic.com/~lynn/2004p.html#63 Systems software versus applications software definitions
https://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
https://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
https://www.garlic.com/~lynn/2005n.html#26 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2006n.html#20 The System/360 Model 20 Wasn't As Bad As All That

How the Classical Scholars dropped security from the canon of Computer Science

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: October 5, 2006 03:14 PM
Subject: How the Classical Scholars dropped security from the canon of Computer Science
Blog: Financial Cryptography

there is something of an analogy with driving ... long ago you could have an environment that didn't have bumpers, safety glass, collapsible steering column, padded dashboard, safetybelts, door locks, anti-theft devices, alarms, air bags, guard rails, impact barriers, crush zones, stop signs, and a ton of other countermeasures for all the possible bad things that might happen.

part of the current programming state of the art ... is that it appears that nearly all of the countermeasures have to be re-invented from scratch for every new effort (if there is any attempt to address the issues at all).

note that in some of the scenarios ... a particular piece of software is more like a single component ... like the engine ... so a lot of the necessary countermeasures aren't part of the engine operation ... it would be part of other components.

a basic issue is designing and implementing an overall infrastructure that has all the necessary countermeasures designed in as part of the fundamental operation .... aftermarket piecemeal is significantly less effective than having it all designed in from the start.

re:
https://www.garlic.com/~lynn/aadsm25.htm#37 How the Classical Scholars dropped security from the canon of Computer Science

another scenario ... is the x9.59 paradigm change.

if you take the security acronym PAIN

P -- privacy (or sometimes cain and confidentiality)
A -- authentication
I -- integrity
N -- non-repudiation

much of the current retail payment environment is dependent on privacy (information hiding and encryption). the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments (as part of the x9.59 standard work)
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

x9.59 changed the paradigm and requires integrity and authentication ... but no longer requires data hiding encryption (privacy) as part of the transaction in order to preserve the integrity of the financial infrastructure for all retail payments.

this is somewhat the past comments about moving away from naked payment/transaction paradigm:
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
https://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
https://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
https://www.garlic.com/~lynn/aadsm25.htm#25 RSA SecurID SID800 Token vulnerable by design
https://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
https://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
https://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt
https://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues

How the Classical Scholars dropped security from the canon of Computer Science

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: October 5, 2006 07:43 PM
Subject: How the Classical Scholars dropped security from the canon of Computer Science
Blog: Financial Cryptography

i guess i have to admit to being on a roll. re:
https://www.garlic.com/~lynn/aadsm25.htm#37
https://www.garlic.com/~lynn/aadsm25.htm#38

one of the big issues is inadequate design and/or assumptions ... in part, failing to assume that the operating environment is an extremely hostile environment with an enormous number of bad things that can happen.

i would even assert that the enormous amounts of money spent attempting to patch an inadequate implementation can be orders of magnitude larger than the cost of doing it right in the first place.

some of this is security proportional to risk ... where it is also fundamdental that what may be at risk is correctly identified.

this is my old standby security proportional to risk posting
https://www.garlic.com/~lynn/2001h.html#61

these are postings in a pki/ca security proportional to risk thread from today
https://www.garlic.com/~lynn/2006s.html#4
https://www.garlic.com/~lynn/2006s.html#5

and as i've observed before that possibly part of the yes card exploits has been assumptions that there would be attacks on the chipcard ... where, in fact, the yes card attacks are on the terminal and infrastructure (and the chipcard attack countermeasures pretty much failed to address terminal/infrastructure attacks at all)
https://www.garlic.com/~lynn/subintegrity.html#yescard

Why security training is really important (and it ain't anything to do with security!)

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: October 6, 2006 11:01 AM
Subject: Why security training is really important (and it ain't anything to do with security!)
Blog: Financial Cryptography

re:
https://financialcryptography.com/mt/archives/000825.html

and:
https://www.garlic.com/~lynn/aadsm25.htm#37 How the Classical Scholars dropped security from the canon of Computer Science
https://www.garlic.com/~lynn/aadsm25.htm#38 How the Classical Scholars dropped security from the canon of Computer Science
https://www.garlic.com/~lynn/aadsm25.htm#39 How the Classical Scholars dropped security from the canon of Computer Science

note that some of the security issues were extremely well understood in the 60s & 70s ... where systems designed for commercial timesharing operation had some fundamental integrity operations built into the basic operation ... and they had little of the vulnerabilities seen in many of the more modern systems.

i've frequently contended that it involves many of the original design and environment assumptions. many of the more modern systems came from a genre of stand-alone, unconnected, personal systems sitting on somebody's kitchen table. there was little reason to design in countermeasures to network-based hostile attacks. many of these systems also developed a large base of applications that depended on taking over the complete system for operation (like the game market). later some of these systems were adapted to closed networks for group collaboration ... again not a basically hostile environment requiring any attack countermeasures.

it was when a large number of these systems started being attached to open, hostile networking environment that a lot of the problems started showing up ... since none of the original design assumptions included operating in such an environment.

i would contend that it is somewhat analogous to taking one of the original horseless carriages and placing it on the track in the middle of a (modern) indy 500 race.

as to the frequent failures of many of the upfront, designed-in security efforts ... one could claim that there was inadequate understanding of the threat and fundamental security principles. of course this can also be attributed to not getting any educational grounding in treats and security.

the counterexample is that many of the systems from the 60s and 70s designed for commercial timesharing (where there is an assumption that different users, would attack each other, given the chance) ... have had much, much lower rate of vulnerabilities.

I was involved in cp67 and vm370 ... originated on 4th floor of 545 tech sq
https://www.garlic.com/~lynn/subtopic.html#545tech

which was used extensively by commercial timesharing service bureaus
https://www.garlic.com/~lynn/submain.html#timeshare

and Multics was done on the 5th floor of the same bldg. multics security reference:
https://www.multicians.org/security.html

until recently buffer overflows were a dominant form of network attacks
https://www.garlic.com/~lynn/subintegrity.html#overflow

which has somewhat given way to networking attacks using various forms of automatic scripting vulnerbilities.

however, a paper from a couple years ago cited the lack of any buffer overflow vulnerabilities in multics
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation

from above:
2.2 Security as Standard Product Feature
2.3 No Buffer Overflows
2.4 Minimizing Complexity
...
This Research Report consists of two invited papers for the Classic Papers section of the 18 th Annual Computer Security Applications Conference (ACSAC) to be held 9-13 December 2002 in Las Vegas, NV. The papers will be available on the web after the conference at
http://www.acsac.org/

The first paper, Thirty Years Later: Lessons from the Multics Security Evaluation, is a commentary on the second paper, discussing the implications of the second paper's results on contemporary computer security issues. Copyright will be transferred on the first paper.

The second paper, Multics Security Evaluation: Vulnerability Analysis is a reprint of a US Air Force report, first published in 1974. It is a government document, approved for public release, distribution unlimited, and is not subject to copyright. This reprint does not include the original computer listings. They can be found at
http://csrc.nist.gov/publications/history/karg74.pdf

... snip ...

Why security training is really important (and it ain't anything to do with security!)

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: October 7, 2006 09:29 PM
Subject: Why security training is really important (and it ain't anything to do with security!)
Blog: Financial Cryptography

re:
https://financialcryptography.com/mt/archives/000825.html

when we did detailed failure mode analysis for tcp/ip stack early in ha/cmp product development (late 80s)
https://www.garlic.com/~lynn/subtopic.html#hacmp

it wasn't necessary human adversaries ... it was just how could things fail. one of the items we noticed then (among lots of others) was the vulnerability to buffer overflows ... both in the way the code was written as well as deficiencies with the C language programming environment. part of this was having worked with tcp/ip stacks written in other languages that rarely, if ever, experienced buffer overflow.
https://www.garlic.com/~lynn/subintegrity.html#overflow

this was subsequently born out also about the Multics study published much later
https://www.garlic.com/~lynn/aadsm25.htm#40 Why security training is really important (and it ain't anything to do with security!)

when we were asked to consult with this small client/server startup that wanted to do payment transactions on their server ... one of the things we did was failure mode matrix for the payment gateway ... and needed a method of handling each possible failure ... regardless of whether it involved a human attacker or not. they had this stuff called SSL and it has somewhat since been come to be called electronic commerce
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

we we started on the x9.59 financial standard electronic retail payment protocol ... the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments.

one of the frequent failure modes that was identified was the skimming/harvesting of account numbers by numerous methods ... including data breaches (much of the identity theft that has been in the news involves this).
https://www.garlic.com/~lynn/subintegrity.html#harvest

rather than attempting to address totally eliminating all possible such data breaches (including those that might involved insiders) ... x9.59 changed the paradigm ... and made such data breaches useless to the attackers.

part of the problem was the diametrically opposing objectives for account numbers ... on one hand they needed to be readily available for scores of different business processes ... and on the other hand they needed to be kept confidential and never revealed
https://www.garlic.com/~lynn/subintegrity.html#secrets

in order to prevent fraudulent transactions
https://www.garlic.com/~lynn/subintegrity.html#fraud

x9.59 changed the paradigm so that the account number can't be used for fraudulent transaction.
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

and therefor eliminated (much of the) data breaches as a security issue ... it didn't do anything to eliminate data breaches ... it just eliminated those data breaches providing any benefit to the attacker.

this is somewhat the security proportional to risk scenario
https://www.garlic.com/~lynn/2001h.html#61

in the above, it didn't eliminate the possibility of such breaches ... it just eliminated any risk that might be associated with such breaches.

for some drift ... a more recent security proportional to risk thread
https://www.garlic.com/~lynn/2006s.html#4
https://www.garlic.com/~lynn/2006s.html#5
https://www.garlic.com/~lynn/2006s.html#9
https://www.garlic.com/~lynn/2006s.html#10

Why security training is really important (and it ain't anything to do with security!)

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: October 7, 2006 10:01 PM
Subject: Why security training is really important (and it ain't anything to do with security!)
Blog: Financial Cryptography

in combination with changing the paradigm for x9.59
https://www.garlic.com/~lynn/aadsm25.htm#41 Why security training is really important (and it ain't anything to do with security!)

we started looking at a generalized authentication mechanism that would replace pin/password ... which became the aads chip strawman in the 1998 timeframe
https://www.garlic.com/~lynn/x959.html#aadsstraw

now if you had a hardware token that never divulged its private key for authentication ... it would be something you have authentication ... and it would have to be physically obtained in order to do some fraud. it wasn't susceptable to the yes card type exploits because it didn't use static data
https://www.garlic.com/~lynn/subintegrity.html#yescard

and, in the case of x9.59 transactions ... the actual transaction was signed and authenticated ... so it wouldn't be vulnerable to any kind of mitm-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

that might still occur with cards doing dynamic data ... but authenticating separately from doing the transaction.

so from 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor

something you have
something you know
something you are

so a card represents something you have authentication. now, normally, multi-factor authentication is assumed to be more secure when the different factors have independent vulnerabilities or failure modes. in the card case, pin/password is nominally a countermeasure to lost/stolen card. however, lack of careful design can result in the yes card exploit ... negating any assumption about independent failure modes.

so there is the problem with people having to deal with scores (or possibly hundreds) of passwords, leading to the password post-it note scenario. in theory, card authentication could replace all the pin/passwords. however, in the existing institutional-centric model, that eventually leads to each of the scores (or hundreds) of passwords for a person being replaced with a (different) card. this in itself, is an untenable solution ... but if each card than has a different pin/password ... then the person has to write the appropriate pin/password on each card (again negating any security asumptions related to multi-factor authentication).

so one of the efforts in the aads chip strawman was looking at what might be necessary to switch from a institutional-centric model to a person-centric model ... where a person might have a single (or extremely few) hardware tokens ... that they could register every place there was a requirement for authentication (potentially resulting in a person having only a single hardware token and a single pin to remember)

misc. past posts mentioning what enablers would be needed to transition to a person-centric authentication infrastructure
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#6 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#36 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm21.htm#2 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
https://www.garlic.com/~lynn/2003o.html#9 Bank security question (newbie question)
https://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2004q.html#0 Single User: Password or Certificate
https://www.garlic.com/~lynn/2005g.html#8 On smartcards and card readers
https://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005m.html#37 public key authentication
https://www.garlic.com/~lynn/2005p.html#6 Innovative password security
https://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
https://www.garlic.com/~lynn/2005r.html#25 PCI audit compliance
https://www.garlic.com/~lynn/2005r.html#31 Symbols vs letters as passphrase?
https://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
https://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
https://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
https://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?

Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates

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

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: October 10, 2006 02:29 PM
Subject: Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates...
Blog: Financial Cryptography

re:
https://financialcryptography.com/mt/archives/000819.html

i was at a european financial conference last fall where i brought up various issues with the (in)ability of sox to identify/prevent corporate crime; this years conference was held last week and its theme was global risks and investor confidence, in part inspired by some of the sox discussions last year.

old posting mentioning conference and sox
https://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley

as well as some posts in thread here
https://financialcryptography.com/mt/archives/000797.html

i.e.
https://www.garlic.com/~lynn/aadsm25.htm#12 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#14 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#15 Sarbanes-Oxley is what you get when you don't do FC

TPM & disk crypto

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: TPM & disk crypto
Date: Thu, 12 Oct 2006 08:43:12 -0600
To: cyphrpunk <cyphrpunk@xxxxxxxx>
CC: cryptography@xxxxxxxx

cyphrpunk wrote:
1. The issue is still moot at present. We are a long way from where open, public, remote attestion will be possible. See this diagram from the Trousers open-source TPM software stack project which shows which pieces are still missing:
http://trousers.sourceforge.net/remote_attestation_deps.png

so i did do fab process and associated infrastructure for tpm-like chips that recorded public key at manufacturing time. this came up in recent thread on trusting chips and/or knowing integrity level of chips
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#5 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP: snake oil or good idea?

hashes on restricted domains: random functions or permutations?

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: hashes on restricted domains: random functions or permutations?
Date: Tue, 17 Oct 2006 22:26:08 -0600
To: Travis H. <solinym@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>

Travis H. wrote:
So I was reading about the OTP system (based on S/Key) described in RFC 2289. It basically hashes a secret several times (with salt to individualize it) and stores the value that the correct password will hash to.

Now my question is, if we restrict ourselves to, say, 160-bit inputs, is SHA-1 a permutation, or do collisions exist? If there are collisions, then iterating the hash could lead to fewer possible values each time, potentially converging on a set of inputs that form a permutation and are closed under composition.

Is that correct? What are the expected sizes of such sets? Is it worth worrying about?

posts discussing other kinds of attack on 2289 ... assuming the original circumstances that 2289 is supposed to address; most of the "fixes" for the attacks ... in turn, negate/invalidate the original purpose/justification for 2289
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?
https://www.garlic.com/~lynn/2005o.html#0 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
https://www.garlic.com/~lynn/2005t.html#31 Looking for Information on password systems
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"

Flaw exploited in RFID-enabled passports

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Flaw exploited in RFID-enabled passports
Date: Sat, 28 Oct 2006 15:21:16 -0600
To: cryptography@xxxxxxxx

Flaw exploited in RFID-enabled passports
http://news.com.com/2061-10789_3-6130396.html?part=rss&tag=6130396&subj=news

from above:
Security researchers have released proof-of-contact code that they say enables an attacker to read the passport number, date of birth, and passport expiration date from passports with RFID tags enabled.

... snip ...

also
http://www.interesting-people.org/archives/interesting-people/200610/msg00162.html

something similar could be claimed behind the switch-over from x.509 identity certificates to relying-party-only digital certificates in the mid-90s (i.e. potentially serious privacy and liability issues)
https://www.garlic.com/~lynn/subpubkey.html#rpo

and as i've pointed out repeatedly, it is trivial to then show that such relying-party-only digital certificates are redundant and superfluous.

then from three factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor

something you have
something you know
something you are

part of the issue with something like date of birth is that it not only is a privacy issue but it may also represent a serious identity theft and fraud issue, in part because there is pervasive use of date of birth as part of something you know authentication.

if the paradigm was sanitized ... then you might at most have something you have authentication ... i.e. you assert some passport number which is in turn, digitally signed by some hardware token or other embedded chip.
https://www.garlic.com/~lynn/subpubkey.html#certless

even simpler, you have anything that asserts some sort of passport number. the challenger than does real-time online lookup (using the supplied number) for photo along with other identifying and/or pertinent information ... and performs authentication based on the information just looked up. a person could carry their passport number in some sort of cellphone/pda ... which requires some response from the owner for it to be transmitted (in response to a query) ... or alternatively ... as a barcode pasted to the back of their cellphone.

The online, real-time scenario would even eliminate the person needing to carry some gov. issued registered document ... just that they are able to provide the appropriate passport number when challenged (which is used to do real-time retrieval of the necessary registered information). The returned real-time information reponse can be specific and limited to the task being performed.

One of the paradigm issues with documents/certificates issued for purely offline operation ... is a tendency to try and make them (more) useful for multiple purposes ... which then leads to them being overloaded with lots of different information for the multiple purposes. Many times there is real danger that the available aggregate information is far in excess of what is needed for any specific task/process. However, it is poor human factors to burden an individual with large set of different documents/certificates that would be exactly specific for every individual operation/process.

AADS Postings and Posting Index, - previous - next - home