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
http://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 parameterized 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
http://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 parameterized 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 parameterized 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 parameterized 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 parameterized 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 parameterized 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)
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
http://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:
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes

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

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

From: wheeler
Date: Wed, 17Nov1999 14:13:42 -0800
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 ...

i.e. origin for:
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snoke or or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snoke or or good idea?
http://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:
http://www.garlic.com/~lynn/x959.html#aads

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

previous post discussing person-centric operation
http://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:
https://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):
http://www.garlic.com/~lynn/2006o.html#16 Gen 2 EPC Protocol Approved as ISO 18000-6C
http://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:
http://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
http://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.
http://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#43 DDA cards may address the UK Chip&Pin woes

related thread:
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV
along with:
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defind chip IP: snake oil or good idea?
http://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
http://www.garlic.com/~lynn/aadsm25.htm#7

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

and other parts of the thread
http://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#5 Crypto to defend chip IP: snake oil or good idea?
http://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
http://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security

the above also drifted into the subject of security proportional to risk ... unrelated post
http://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)
http://www.garlic.com/~lynn/subtopic.html#360pcm

of course, the response/countermeasure to PCM was FS ... lots of past FS posts
http://www.garlic.com/~lynn/subtopic.html#futuresys
a specific post discussing FS countermeasure to PCM
http://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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

compared to x9.59 financial standard using transaction strong authentication
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
http://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
http://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.mercurynews.com/mld/mercurynews/news/breaking_news/15207887.htm
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:
http://www.garlic.com/~lynn/aadsm19.htm#10 Security as a "Consumer Choice" model or as a sales (SANS) model?
http://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#10 PGP "master keys"
http://www.garlic.com/~lynn/aadsm24.htm#35 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#36 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#39 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#40 Interesting bit of a quote
http://www.garlic.com/~lynn/2006.html#12a sox, auditing, finding improprieties
http://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
http://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley
http://www.garlic.com/~lynn/2006j.html#28 Password Complexity
http://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:
http://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
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
http://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
http://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
http://www.garlic.com/~lynn/2001.html#45 what is UART?
http://www.garlic.com/~lynn/2003k.html#11 humor in source code
http://www.garlic.com/~lynn/2003k.html#37 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2005k.html#26 More on garbage
http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006h.html#26 Security
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
http://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:
http://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 parameterized risk management ... mentioned in these posts
http://www.garlic.com/~lynn/aadsm25.htm#1
http://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
http://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=191901528

... and for a little drift on the basel II topic
http://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
http://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
http://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)
http://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
http://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
http://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).
http://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 succesful 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 succesful 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).
http://www.garlic.com/~lynn/x959.html#x959
http://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)
http://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
http://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:
http://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:
http://www.garlic.com/~lynn/aadsm25.htm#17 Hamiltonian path as protection against DOS

so much of postings at
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://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
http://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:
http://www.garlic.com/~lynn/aadsm25.htm#17 Hamiltonian path as protection against DOS
http://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)
http://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
http://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:
http://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
http://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:
http://www.garlic.com/~lynn/aadsm25.htm#17
http://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
http://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.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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
http://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
http://www.garlic.com/~lynn/96.html#34 Mainframes & Unix
http://www.garlic.com/~lynn/99.html#16 Old Computers
http://www.garlic.com/~lynn/99.html#158 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#159 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on PowerPC?)
http://www.garlic.com/~lynn/2002.html#23 Buffer overflow
http://www.garlic.com/~lynn/2002.html#32 Buffer overflow
http://www.garlic.com/~lynn/2002.html#34 Buffer overflow
http://www.garlic.com/~lynn/2003.html#30 Round robin IS NOT load balancing (?)
http://www.garlic.com/~lynn/2003.html#33 Round robin IS NOT load balancing (?)
http://www.garlic.com/~lynn/2003c.html#8 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#12 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#25 Network separation using host w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment
http://www.garlic.com/~lynn/2004k.html#32 Frontiernet insists on being my firewall
http://www.garlic.com/~lynn/2004o.html#53 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2005f.html#55 What is the "name" of a system?
http://www.garlic.com/~lynn/2005g.html#21 Protocol stack - disadvantages (revision)
http://www.garlic.com/~lynn/2005n.html#5 Wildcard SSL Certificates
http://www.garlic.com/~lynn/2005n.html#34 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005o.html#24 is a computer like an airport?
http://www.garlic.com/~lynn/2005r.html#32 How does the internet really look like ?
http://www.garlic.com/~lynn/2005r.html#39 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006j.html#15 30 hop limit

Introducing the new HavenCo location

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

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
http://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
http://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
http://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?
http://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?
http://www.garlic.com/~lynn/2006k.html#2
http://www.garlic.com/~lynn/2006k.html#17
http://www.garlic.com/~lynn/2006k.html#18
http://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:
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#29 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#37 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#43 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#50 DDA cards may address the UK Chip&Pin woes
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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:
http://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).
http://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.
http://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:
http://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)
http://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
http://www