Misc AADS & X9.59 Discussions


AADS Postings and Posting Index,
next, previous - home



dual-use digital signature vulnerability
dual-use digital signature vulnerability
dual-use digital signature vulnerability
dual-use digital signature vulnerability
dual-use digital signature vulnerability
Using crypto against Phishing, Spoofing and Spamming
dual-use digital signature vulnerability
Using crypto against Phishing, Spoofing and Spamming
E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
dual-use digital signature vulnerability
dual-use digital signature vulnerability
In Search of Eve - the upper boundary on Mallory
In Search of Eve - the upper boundary on Mallory
In Search of Eve - the upper boundary on Mallory
should you trust CAs? (Re: dual-use digital signature vulnerability)
Any TLS server key compromises?
RPOW - Reusable Proofs of Work
RPOW - Reusable Proofs of Work
RFC 3833 Threat analysis of the domain name system (DNS)
[anonsec] Re: potential new IETF WG on anonymous IPSec
public-key: the wrong model for email?
public-key: the wrong model for email?
public-key: the wrong model for email?
public-key: the wrong model for email?
EMV cards as identity cards
x9.99 privacy note
EMV cards as identity cards
Academics locked out by tight visa controls
EMV cards as identity cards
EMV cards as identity cards
An interesting "new" computer security problem
An interesting "new" computer security problem
Credit card leaks continue at a furious pace
Phishing losses total $500 million - Nacha
Fake Companies, real money; elaborate con wrings cash out of stolen credit cards
How to store the car-valued bearer bond? (was Financial identity...)
Financial identity is *dangerous*? (was re: Fake companies, real money)
Financial identity is *dangerous*? (was re: Fake companies, real money)
Adding reliability and trust to smartcards
Payment Application Programmers Interface (API) for IOTP
SSL/TLS passive sniffing
SSL/TLS passive sniffing
Banks Test ID Device for Online Security
Banks Test ID Device for Online Security
Dell to Add Security Chip to PCs
Dell to Add Security Chip to PCs
one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
link-layer encryptors for Ethernet?
link-layer encryptors for Ethernet?
A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
ATM machine security
MD5 collision in X509 certificates
MD5 collision in X509 certificates
two-factor authentication problems


dual-use digital signature vulnerability

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 Jul 2004 10:32:44 -0600
To: Amir Herzberg <herzbea@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxxx>, cryptography@xxxxxxxx
start of post:
https://www.garlic.com/~lynn/aadsm17.htm#59

the fundamental issue is that there are infrastructures using the same public/private key pair to digital sign

1) random authentication data that signer never looks at and believe is of low value ... i.e. if they connect to anybody at all ... and are asked to digitally sign some random data for authentication purposes ... they do it.

2) contents that they supposedly have read, understood, agrees, approves, and/or authorizes.

i haven't seen any definition of data arriving at the relying party where the relying party has proof of whether it was case #1 or case #2. The closest was the non-repudiation bit in a certificate. however, the non-repudiation bit in a certificate was put in there at the time the certificate was manufactured and in no way applies to the environment and conditions under which the signature in question actually occurred.

there are definitions like non-repudiation services and/or the EU FINREAD definition ... which purports to specify the environment under which the (real) "signatures" take place. Note however, while the EU FINREAD defines an environment where there is some indication that the signing party might have read and agreed to the contents of what is being signed .... there is nothing in the EU FINREAD specification that would provide proof to the relying party that a FINREAD terminal was actually used for any specific signing. Anything, like a flag ... not part of a signed message ... that might be appended to the transmission ... that makes claims about whether a FINREAD terminal was used or not ... could have originated from anywhere .... analogous to the example where a relying party might be able to substitute a certificate with the non-repudiation bit set .... in order to change the burden of proof from the relying party to the signing party ... in a legal dispute ... more the mid-90s ... where non-repudiation flag in a certificate might have been thought to have some valid meaning (since the certificate wasn't covered by the signature .... anybody could claim any valid certificate was the certificate used for the transaction)

In any case, if a signing party has ever used their private key to sign random data that they haven't read ..... and they are ever expected to use the same private key in legal signing operations where they are presumed to have read, understood, agrees, approves, and/or authorizes the contents .... and there is no proof provided (or included) as part of the signed message that the signing occurred in a specified (non-repudiation) environment ... then there is no way that a relying party can prove or disprove under what conditions a digital signing actually occurred.

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

dual-use digital signature vulnerability

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 Jul 2004 11:25:17 -0600
To: Sean Smith <sws@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
    Amir Herzberg <herzbea@xxxxxxxx>, cryptography@xxxxxxxx
At 10:36 AM 7/18/2004, Sean Smith wrote:
In SSL and TLS, the client isn't signing random data provided by the adversary. Rather, the client is signing a value derived from data both the client and server provide as part of the handshake. I do not believe it is feasible for a malicious server to choose its nonces so that the resulting signature be coincide with a valid signature on a delegation cert the client might have constructed.

the issue in the EU FINREAD scenario was that they needed a way to distinguish between (random) data that got signed ... that the key owner never read .... and the case were the key owner was actually signing to indicate agreement, approval, and/or authorization. They specified a FINREAD terminal which supposedly met the requirements that the key owner had to have read and to some extent understood .... and approved as to the meaning of the contents of what was being signed.

However, the FINREAD specification didn't define any mechanism that provided proof to the relying party that a FINREAD terminal was actually used as part of the signature process.

Some of the non-repudiation service definitions also talk about processes that would provide high likelyhood that the person performing the signing has read, understood, agrees, approves, and/or authorizes the contents of what is being signed. However, many of them fail to specify a mechanism that proves to a relying party that such a non-repudiation service was actually used.

so the dual-use attack .... is if a key-owner ever, at any time, signs something w/o reading it ... then there is the possibility that the data being signed actually contains something of significance.

if there is never any proof, included as part of the integrity of the message ... that proves to the relying party that some sort of non-repudiation environment was used as part of the digital signing .... then it falls back on requiring an exhaustive proof that never in the history of the private key was it ever used to sign contents that were unread and could possibly be used in a dual-use attack.

it isn't sufficient that you show there is some specific authentication protocol with unread, random data ... that has countermeasures against a dual-use attack ... but you have to exhaustively show that the private key has never, ever signed any unread random data that failed to contain dual-use attack countermeasure

the alternative to the exhaustive proof about every use of the private key .... is strong proof (that is built into the integrity of the signed contents) that non-repudiation environment was used for the digital signing (strong implication that the key owner, read, understood, agrees, approves, and/or authorizes the contents of the message).

the NIST alternative scenario for a exhaustive proof ... rather than exhaustive proof about every use of a specific private key .... would be able to show that it is impossible to use the private keys in any protocol not written by the people making the presentation

this came up in a SET discussion long ago and far away. it was about whether there was ever any SET gateway implementation that could set the signature verified bit in the ISO 8583 message. One of the SET vendors claimed that the software they shipped was certified that it would never set the signature verified bit in the ISO 8583 message, if the signature hadn't actually been verified (and therefor there wasn't an infrastructure vulnerability). The problem was that they had created an infrastructure that didn't require end-to-end proof of the signature verification ... and they were unable to control that every ISO 8583 generated message .... was certified as only being able to be generated by their code. They had created an infrastructure vulnerability .... that allowed a wide variety of software to be used .... and was only safe if they could prove that every copy of code generating every ISO 8583 messages was their code and it was impossible to modify and/or substitute something else in the generation of an ISO 8583 message.

The countermeasure to the seriously flawed SET design requiring exhaustive proof that every ISO 8583 message that was ever created that carried the signature verified bit .... could have only been created by unmodified, certified software .... was to support end-to-end authentication. ... And for a slight drift ... that wasn't practical in the SET design because the inclusion of a certificate would have represented horrendous payload bloat of two orders of magnitude (discussed in some detail in recent previous posts to this mailing list)

https://www.garlic.com/~lynn/aadsm17.htm#53 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming

dual-use digital signature vulnerability

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** Refed: ** -, ** -, ** -, **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 Jul 2004 13:28:17 -0600
To: Amir Herzberg <herzbea@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: cryptography@xxxxxxxx
there is a variation on the EU FINREAD terminal that sort of provides a chain of trust/evidence (that has almost nothing at all to do with the traditional trusted third party certification authorities and their certificates)
  1. there ae a certain class of certified terminals with security modules, tamper evident, and are known to always present an accurate text of what is about to be signed ... and then ask the person if they agree with what was presented .... which they have to indicate by pressing some button (or set of buttons)
  2. there are a certain class of certified hardware tokens which contain unique private keys.
  3. the specific certified hardware terminals are able to verify what kind of hardware token they are dealing with and only work with the appropriate hardware token
  4. the specific certified hardware tokens are able to verify what kind of terminal they are dealing with and only work with the appropriate hardware terminals.
  5. relying party gets a signed message
  6. the relying party can verify the digital signature with a specific public key known to be associated with a known hardware token
  7. the known hardware token is known to be in the possession of a specific person .... which implies something you have authentication
  8. the known hardware token is known to satisfy requirements #2 and #4
  9. the corresponding terminals that the hardware token works with are known to satisfy requirements #1 and #4
  10. given conditions 1-9, the relying party has some assurance that the token owner has actually read, understood, agrees, approves, and/or authorizes the contents of the message.
In this scenario, the relying party wouldn't need direct evidence included as part of the integrity of each message that the signing took place in an non-repudiation environment .... the infrastructure assurance as to the kind of terminals, tokens, and procedures provide such indirect evidence as part of the infrastructure operation (aka the chain of evidence/trust scenario .... having nothing at all to do with traditional third party certification authorities and their certificates).

This kind of scenario falls apart .... if the hardware token ever digitallly signs some contents that is not provided by a trusted terminal. In which case the chain of evidence/trust is lost as to whether the token owner has read, understood, agrees, approves, and/or authorizes the contents of every message that has been signed (thus allowing a dual-use attack).

Either you
  1. have some proof that every use of the specific hardware token (and its corresponding unique private key) digital signing always meets the requirements laid out as to human reading, understanding and agreeing, approving and/or authorizes the contents of what is being signed ... and it can never be used in any other way (precluding a dual-use attack).
  2. or that every use of the specific hardware token (and its corresponding unique private key) digital signing that is purported to meet the requirement for human reading, understanding and agreeing, approving and/or authorizes the contents of what is being signed .... carries in the integrity part of the message some indication/proof of the human reading, understanding and agreeing, approving and/or authorizes (and that indication can't be fraudulently fabricated if the hardware token was to ever be used in signing some message that doesn't involve reading/understanding/approval by the token owner) (precluding a dual-use attack).


dual-use digital signature vulnerability

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 Jul 2004 23:51:28 -0600
To: Sean Smith <sws@cs.xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: cryptography@xxxxxxxx
At 08:08 PM 7/18/2004, Sean Smith wrote:
Why isn't it sufficient? (Quick: when was the last time anyone on this list authenticated by signing unread random data?)

The way the industry is going, user keypairs live in a desktop keystore, and are used for very few applications. I'd bet the vast majority of usages are client-side SSL, signing, and encryption.

If this de facto universal usage suite contains exactly one authentication protocol that has a built-in countermeasure, then when this becomes solid, we're done.


so if digital signing is used for nothing else than authentication ... with signing of challenge data (with or with/out client-side modification) ... then there is no concern that something signed might be a document or authorization form. it is a non-problem.

EMV chipcards are supposed to be doing dynamic data RSA signing of authorized transactions ... at some point, real soon now ... and the financial industry is writing some number of apps to be able to use the EMV cards for other applications.

this is from yesterday http://www.smartcardalliance.org/industry_news/industry_news_item.cfm?itemID=1316

which talks about additional applications (in addition to expected RSA signing at EMV point-of-sale terminals)
• OneSMART MasterCard Authentication - ensures a higher level of security for online shopping and remote banking
• OneSMART MasterCard Web - allows cardholders to securely store and manage a wide range of personal data (such as names, addresses, URLs, log-on passwords) on the smart card chip
• OneSMART MasterCard Pre-Authorised - a new chip-based payment solution suitable for new markets and off-line payment environments


===

it doesn't give any details but possibly if the expected RSA signing at EMV point-of-sale terminals is an example of aggreement/approval ... then the authentication application may be RSA signing of some sort of challenge data .... and i would guess that few, if any people make it a habit to examine presented challenge data.

part of the issue is creating an environment where all authentication protocols and all authentication implements are required to have countermeasures against dual-use attack on signing of documents or transactions ... means that loads of stuff have to be perfect in the future.

the other is requiring more proof regarding the signing environment to be carried when the signing is associated with approval, agreement, and/or authorization (more than simple authentication) .... for instance that for some of the non-repudiation features (that supposedly address such issues) .... that they have to also sign in some manner to indicate non-repudiation features being in place.

dual-use digital signature vulnerability

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 19 Jul 2004 09:26:18 -0600
To: Jerrold Leichter <jerrold.leichter@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: Sean Smith <sws@xxxxxxxx>,
   Amir Herzberg <herzbea@xxxxxxxx>, cryptography@xxxxxxxx
At 08:25 AM 7/19/2004, Jerrold Leichter wrote:
A traditional "notary public", in modern terms, would be a tamper-resistant device which would take as inputs (a) a piece of text; (b) a means for signing (e.g., a hardware token). It would first present the actual text that is being signed to the party attempting to do the signing, in some unambiguous form (e.g., no invisible fonts - it would provide you with a high degree of assurance that you had actually seen every bit of what you were signing). The signing party would indicate assent to what was in the text. The notary might, or might not - depending on the "means for signing" -

note that some of the online click-thru "contracts" have been making attempt to address this area; rather than simple "i agree"/"disagree" buttons ... they put little checkmarks at places in scrolled form .... you have to at least scroll thru the document and click on one or more checkmarks .... before doing the "i agree" button. a digital signature has somewhat higher integrity than simple clicking on the "i agree" button ... but wouldn't subsume the efforts to demonstrate that a person was required to make some effort to view document. Of course in various attack scenarios ... simple checkmark clicks could be forged. However, the issue being addressed isn't a forging attack ... it is person repudiating that they read the T&Cs before hitting the "I agree" button.

With the depreciating of the non-repudiation bits in a long ago, and far away manufactured certificates (which has possibly absolutely no relevance to the conditions under which digital signatures are actually performed) .... there has been some evolution of non-repudiation processes. An issue for the non-repudiation processes is whether or not the person actually paid attention to what they were "signing" (regardless of the reason).

An issue for relying parties is not only was whether or not there was some non-repudiation process in effect, but also does the relying party have any proof regarding a non-repudiation process. If there is some risk and/or expense associated with repudiation occurring (regardless of whether or not it is 3rd party fraud/attack issue), then a relying party might adjust the factors they use for performing some operation (i.e. they might not care as much if it is a low-value withdrawal transaction for $20 than if it was a withdrawal transaction for $1m).

some physical contracts are now adding requirement that addition to signing (the last page), that people are also required to initial significant paragraphs at various places in the contract.

Using crypto against Phishing, Spoofing and Spamming

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 21 Jul 2004 10:10:24 -0600
To: "Steven M. Bellovin" <smb@xxxxxxxx>
Subject: Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: Ian Grigg <iang@xxxxxxxx>, EKR <ekr@xxxxxxxx>,
    Florian Weimer <fw@xxxxxxxx>, cryptography@xxxxxxxx
At 01:54 PM 7/19/2004, Steven M. Bellovin wrote:
It's also worth remembering that an SSL-like solution -- cryptographically protecting the transmission of credit card number, instead of digitally signing a funds transfer authorization linked to some account -- was more or less the only thing possible at the time. The Internet as a medium of commerce was too new for the banks to have developed something SET-like, and there wasn't an overwhelmingly-dominant client platform at the time for which custom software could be developed. (Remember that Windows 95 was the first version with an integral TCP/IP stack.) *All* that Netscape could deploy was something that lived in just the browser and Web server. SET itself failed because the incentives were never there -- consumers didn't perceive any benefit to installing funky software, and merchants weren't given much incentive to encourage it.

SET couldn't replace online transaction ... the encryption was effectively there for hiding credit card while in-flight ... which SSL was already doing ... but SET was doing at an order to two-orders increase in complexity and overhead. SET didn't provide any additional countermeasure against the major exploits/vulnerabilities (vis-a-vis SSL) ... even with all that complexity.

the transaction was still online ... since there are a bunch of other factors involved in authorization ... like credit limit ... not just whether there is impersonation with lost/stoleln numbers.

there was still the enormous payload bloat (certificates and signatures increase the size of typical 8583 transaction by two-orders of magnitude) which prevent true end-to-end security operation. As a result the signature was verified at some internet boundary, then the signature and certificate(s) were stripped off and traditional 8583 packet forwarded to the consumer/issuing financial institution. Later at some ISO standards meeting, one of the association business people presented numbers on number of 8583 packets with the signature bit turned on and they positively knew no digital signature was involved.

It wasn't even a real PKI ...

1) i.e. the x.509 identity certificates from the early 90s had been depreciated because of the privacy and liability issues ... and the certificates effectively were issuing relying-party-only certificates with the account number and public key.

2) there was no revocation and/or other types of process (which could be considered minimum requirement for a PKI operation) ... they were simply manufactured certificates (a term we coined to describe the SET and SSL infrastructure; contrasting it to PKI). SET specifically stated that the transaction would be online and rely on the existing online infrastructure for determining lost, stolen, revoked, canceled, etc ... as well as all the other stuff an online infrastructure can do with timely and aggregated information (like credit limit)

3) it is trivial to show that for relying-party-only certificates requiring online infrastructure ... that the certificates themselves are redundant and superfluous ... aka the key is registered with the issuing party ... and the transaction is performed by the issuing party. The transaction can be digitally signed (w/o the enormous payload bloat of carrying a certificate) and the issuing party verify the digital signature with an onfile public key .... w/o having to resort to dealing with a certificate (that the issuing party would have originally generated from the onfile information).

From an incentive standpoint the PKI model is effectively orthogonal to standard business processes.

The key owner pays something to the issuing party (or at best, the issuing party absorbs the costs). The standard business process has any sort of contract between the key owner and the issuing party.

This totally leaves out the relying-party ... which is the primary beneficiary of the PKI model from being a part of the contractual business process ... which would imply little or no legal recourse if something went wrong. GAO has created a facade to address this issue by making the TTP certification authorities sort of agents of the GAO ... and having all relying-parties signed contracts with the GAO., The PKI frequently creates a total disconnect between the parties of the certification "contract" ... and the relying parties ... which should have recourse in case something went wrong aren't even a part of it.

In the specifics of the SET deployment ... the primary potential beneficiaries theoretically were the merchants (from the thoery that SET signed transactions would be considered card-present & card-owner present ... and lower the merchants cost for doing the transactions). However the parties "paying" for the certificates and most of the infrastructure were the issuers and the consumers. Not only may a traditional TTP PKI create legal disconnect for relying parties .... but in the SET case there was major disconnect between who paid for most of the infrastructure and who benefited (i.e. need some sort of mechanism to get the merchants to pay for the consumer's certificate .... even tho the certificates were functionally redundant and superfluous).

dual-use digital signature vulnerability

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 22 Jul 2004 08:34:25 -0600
To: Amir Herzberg <herzbea@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: Barney Wolff <barney@xxxxxxxx>, Anton Stiglic <astiglic@xxxxxxxx>,
    cryptography@xxxxxxx
At 05:37 AM 7/22/2004, Amir Herzberg wrote:
Most (secure) signature schemes actually include the randomization as part of their process, so adding nonces to the text before signing is not necessary. OTOH, I don't see any problem in defining between the parties (in the 'meta-contract' defining their use of public key signatures) that the signed documents are structured with a random field before and after the 'actual contract', as long as the fields are well defined.

there has been some claim that large random nonces as part of message ... before hashing and signing is characteristic of RSA signatures. one of the issues with DSA and hardware tokens in the 90s was that none of the hardware tokens had reliable random generators. If you were doing DSA (or ECDSA) infrastructure ... then integrity was dependent on quality random generator as part of the signature process (to preserve the integrity of the private key). In some sense, large random nonces (as part of the content to be signed) was shifted to the party(s) generating the message as part of the RSA process. In theory, DSA/ECDSA eliminates that requirement ... especially as you move in to the late 90s where hardware tokens started to appear that had quality random generators.

protocols have had servers contributing unique values in signed messages .... in things like authentication protocol .... as countermeasure to replay attacks (on the server).

protocols have had clients contributing some values in signed messages ... in an authentication protocol ... as countermeasure of server attacks on clients. It isn't necessary that the client contributed part has to bracket both the start and end of the message .... in a digital signature environment ... since the digital signature protects the whole message integrity. The client contributed part could be simple readable text disclaimer ... comparable to some disclaimers you see at the bottom of emails (especially from lawyers, doctors, and/or people that work for such firms .... you even see it in various mailing lists by people that work for the big accounting firms).

sometimes the recommendations are that both server and client contribute something unique to the signed message ... as generic countermeasures ... regardless of whether the situation is actually vulnerable to the associated attacks. In general, where the server incurs some expense and/or liability associated with every message ... the server (or relying-party) is probably interested in countermeasures against replay attacks.

one of the requirements given x9a10 working group (for the x9.59 protocol) ... was to be able to perform the operation in a single round-trip .... w/o any sort of protocol chatter. this is comparable to existing electronic payment business process. the countermeasure that the infrastructure uses for replay attacks is to have the transactions time-stamped and log is kept. transactions with time-stamps that predate the log cut-off are deemed invalid. In the x9.59 transaction scenario ... the signing entity (in theory) specifically approved every transactions and used ecdsa signature. the ecdsa signature would preserve the integrity of the transaction. the time-stamp in the transaction would indicate whether it was within the current active log window of the payment processor, and the randomness of the ecdsa signature would provide uniqueness (two transactions that were otherwise identical (in amount, time, etc) would be unique if they had different ecdsa signatures (effectively provided by the definition of dsa & ecdsa).

the addition of ecdsa signature to existing payment transaction .... exactly preserved all the existing business processes and flows ... including the requirement that the client can originate the transaction and the message flow could complete in a single round-trip.

the addition of the ecdsa signature added
  1. integrity of the transaction message,
  2. authenticated the origin, and
  3. provided transaction uniqueness.
no (public key) certificate was required since the transaction was being processed by the relying-party (which in the SET model was also the relying-party, had the public key on file, had the original of all the information that went into a SET relying-party-only certificate, and the only function that the SET relying-party-only certificate was to repeatedly travel from the client to the relying party increasing the payload and the bandwidth requirements by a factor of one hundred times, carrying static, trivial subset of information to the relying party ... which the relying party already had ... making it redundant and superfluous ... other than contributing enormous payload bloat).

there was one additional thing that was specified in x9.59 standard .... that account numbers used in x9.59 transactions could not be used in non-authenticated transactions (note that all the payment processors already supported feature/function of mapping multiple account numbers to the same account). the issue was that it was recognized that regardless of the crypto facilities used to protect the account number in flight, there were scores of business processes that required the account number to appear in the clear.

In the existing infrastructure there are huge numbers of unauthenticated transactions that can be performed with the account number ... which effectively turns the account number into an enormous shared-secret .... requiring enormous amounts of protection for the shared-secret. however, with all the enormous numbers of places that the clear-text account number is used ... it is not practically possible to also preserve the account number as a shared-secret. minor past note about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

so the x9.59 approach was to eliminate shared-secret as a business characteristic of the account numbers used in x9.59 transactions.
https://www.garlic.com/~lynn/x959.html#x959

if an account number used in an (digitally signed) x9.59 transaction ... can only be used in x9.59 (digitally signed) transactions .... it no longer carries with it the shared-secret characteristic (since simple knowledge of the account number is insufficient to impersonate and/or perform fraudulent transactions). So if the insiders at a merchant processing end-point (or an external outsider that is harvesting merchant processing transaction files) is able to "steal" the account number but is not able to use it fraudulently ... it no longer has to be protected as a shared-secret.

The end-point static harvesting of transaction files has been the major vulnerability for a long time. They have tended to be in the clear because of the large number of business processes that require access to the transactions. Neither SET nor SSL provided any countermeasures for this (the major) vulnerability/exploit.

X9.59 did eliminate this as a vulnerability ... since stealing the transaction file and harvesting the account numbers .... would not provide the crook any mechanism to impersonate and/or perform a fraudulent transaction. It turns out the secondary effect was that it was no longer necessary to hide the account number while in flight either (in order to preserve an account number as a shared-secret). digitally signing the transaction both preserved the integrity of the transaction as well as authenticating the origin of the transaction. This then eliminated the requirement to hide the account number as a countermeasure against the account number being exposed (and comprimising its shared-secret characteristic).

The issue with SET was that it was horribly more complex and expensive and provided no fundamental additional protection/countermeasure than existing SSL (with respect to reducing existing vulnerabilities and fraud). This was somewhat orthogonal to the problem with the horribly additional expense not being born by the primary benefiting parties.

X9.59 is an enormously simpler and less expensive protocol than either SET or SSL ... and turns out to address (in a business way) the major exploits and vulnerabilities in the existing infrastructure ... the basic characteristic that the account number is effectively a shared-secret (which neither SET nor SSL addresses). Furthermore, with the elimination of the shared-secret attribute for account numbers .... then it is no longer necessary to encrypt the transmissions (for purposes of preserving the account number secrecy).
https://www.garlic.com/~lynn/subpubkey.html#privacy

Using crypto against Phishing, Spoofing and Spamming

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 22 Jul 2004 13:07:30 -0600
To: Ed Gerck <egerck@xxxxxxxx>
Subject: Re: RP -- Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: cryptography@xxxxxxxx
At 01:39 PM 7/21/2004, Ed Gerck wrote:
The PKI model is not tied to any legal jurisdiction and is not a business process. What is meant then by relying-party (RP) and RP Reliance in X.509 and PKIX? I hope the text below, from a work in progress submitted as an IETF ID, helps clarify this issue.

the TTP (trusted third party) PKI business model typically described in the early 90s ... had a business exchange between a key owner and a certification authority ... where the key owner paid the certification authority for the issuing of a certificate that bound some information to the public key. The payment of money by the key owner to the certification authority created some sort of legal relationship between the key owner and the certification authority .... with regard to the certificate.

in that environment .... the key owner then digitally signed something, and sent the something with a digital signature and the certificate to a relying-party. The relying-party was frequently assumed to be making some sort of legal reliance and recourse on the performance of the certification authority. However, w/o payment of funds and/or other legal arrangement between the relying-party and the certification authority .... there was no legal bases for reliance (unless mandated outside of traditional business context by some gov. mandate)

it appears that the GAO .... working within that semantic & structural business context ... has taken some effort to create a legal basis for reliance and recourse between the relying parties and the certification authorities for the federal PKI . It basically has something along the lines of the certification authorities signing a contractual relationship with the GAO. Then all the relying parties also sign a contractual relationship with the GAO .... then there is recourse for the relying parties on certification authority performance based on the relying parties contract with GAO (for certification authority performance) and the GAOs contract with the certification authorities (for certification authority performance). This is sort of trying to get around the lack of any implied performance and/or contractual relationship (and therefor recourse) because the relying parties haven't actually paid any money to the certification authorities.

In the simple case, having any sort of legal obligation between the certification authority and the key-owner ... and any sort of totally different legal obligation between the key-owner and a relying party ... normally would fail to create any sort of legal obligation between (the traditional TTP PKI) certification authorities (described in the early 90s) and the set of relying parties.

some of this became mute by the mid-90s with the observation that the traditionally considered identity x.509 certificates represented a significant privacy and liability exposure ... and the retrenching by infrastructures to relying-party-only certificates (effectively account number and public key ... although even a relying-party-only SET certificates could represent a factor of 100-times payload bloat). the other issue that quickly became observed if the relying-party and the certification authority were the same .... then the relying party would typically have a large superset of the information that they included in any relying-party-only certificate ... and that having the key-owner to return this small subset of information repeatedly to the relying-party (/certification authority) was redundant and superfluous .... other than possibly contributing huge computational and transmission overheads for no useful purpose.
https://www.garlic.com/~lynn/subpubkey.html#rpo

IETF standards tend to be descriptions of protocol and parties role in the protocol. Such syntactical and semantical description of the protocols has rarely included description of any possible syntactical and semantic business relationships .... especially of the typical kind being proposed in the early 90s for TTP certification authorities.

for pkix references .... see
https://www.garlic.com/~lynn/rfcietff.htm

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

then click on "PKI" in the Acronym fastpath section.

the current results:
public key infrastructure (PKI)
see also authentication , encryption , public key
3820 3779 3778 3770 3741 3739 3709 3653 3647 3562 3447 3379 3354 3335 3281 3280 3279 3278 3275 3174 3163 3161 3156 3126 3125 3110 3076 3075 3039 3029 2986 2985 2943 2931 2898 2847 2807 2803 2802 2797 2726 2693 2692 2587 2585 2560 2559 2537 2536 2535 2528 2527 2511 2510 2459 2440 2437 2404 2403 2385 2315 2314 2313 2311 2202 2154 2137 2085 2082 2065 2025 2015 1991 1864 1852 1828 1810 1751 1544 1424 1423 1422 1421 1321 1320 1319 1186 1115 1114 1113 1040 989


clicking on any RFC number will bring up the RFC summary in the lower frame. Clicking on the ".txt" field in the RFC summary will fetch the actual RFC.

E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: cryptography@xxxxxxxx
Subject: E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
Date: Fri, 23 Jul 2004 09:04:33 -0600
E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good.
http://www.techworld.com/security/news/index.cfm?NewsID=1975

... aka not necessarily an attack on SSL itself ... but identifying end-points with open SSL ports as attack targets i.e. end-points with open SSL ports are likely to be somewhat higher value targets than machines w/o SSL ports .... since the operators possibly feel they have something to protect.

E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good

Date: Fri, 23 Jul 2004 12:08:29 -0600
To: Matt Crawford <crawdad@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
Cc: cryptography@xxxxxxxx
At 11:09 AM 7/23/2004, Matt Crawford wrote:
I can't see any reasonable way to derive your conclusion from the cited article.

"The surge began on 15 July, the day before the public disclosure of a critical flaw in a server module called mod_ssl."

"The last time Netcraft observed similar activity was in April, shortly before a wave of attacks on SSL servers that included the compromise of some major e-commerce sites. Attackers used a flaw in Microsoft's implementation of SSL to install malicious code..."


i just mentioned that it could possible be (another kind of) attack/threat model (other than the obvious referenced in the article).

i wasn't aware that this mailing list would preclude mention of other possible attack/thread models .... other than the obvious ones mentioned.

E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 23 Jul 2004 13:34:22 -0600
To: Matt Crawford <crawdad@xxxxxxxx>
Subject: Re: E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
Cc: cryptography@xxxxxxxx>
slightly more topic drift w/respect to potential/possible threat models ...

i have put quite a bit of work into security taxonomy as part of the merged securitity glossary and taxonomy
https://www.garlic.com/~lynn/index.html#glosnote

i've relatively recently taken a pass at the cve database ...
http://cve.mitre.org/cve/index.html
http://www.osvdb.org/

but what I found was very little structure. i have done word frequency analysis on the descriptions ... but even that isn't really conclusive (since effectvely random people are generating quite random word descriptions). I was hoping to find more structure for expanding taxonomy for threat models, vulnerabilities, and exploits.

E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Matt Crawford <crawdad@fnal.gov>
Cc: cryptography@xxxxxxxx
Subject: Re: E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
Date: Fri, 23 Jul 2004 18:18:40 -0600
here is another article on the same subject
http://thewhir.com/marketwatch/ssl072304.cfm

which includes the following quote
According to Netcraft, SSL, which is used to encrypt sensitive information for e-commerce transactions, points to the presence of sensitive financial data that hackers would be interested in stealing.

which might plausibly be interpreted as attackers associating the presence of an open SSL port as indicating a server/endpoint worthy of attack.

dual-use digital signature vulnerability

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 25 Jul 2004 13:41:56 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
Subject: Re: dual-use digital signature vulnerability
Cc: cryptography@xxxxxxxx, sws@xxxxxxxx, astiglic@xxxxxxx
At 07:07 PM 7/24/2004, Peter Gutmann wrote:
A depressing number of CAs generate the private key themselves and mail out to the client. This is another type of PoP, the CA knows the client has the private key because they've generated it for them.

one could claim that there might be two possible usage scenarios, involving two different threat models: encryption and authentication.

from a business standpoint the encryption of corporate data (especially data at rest .... which might include some of the corporate jewels) can represent single point of failures ... if private key is required for the recovery of corporate jewels and the private key isn't reliably replicated (to avoid single points of failure); then there is a serious, corporate, overriding availability threat.

the claim can be made that the trade-off for authentication and digital signature would result in no escrow nor replication of private key .... since the overriding threat model is a) impersonation and/or b) not being able to reliably attribute certain actions to specific people.

the assertion here is possible threat model confusion when the same exact technology is used for two significantly different business purposes.

.... in general, no key escrow or no key replication is frequently bad in the encryption business process scenario

... while no key escrow or no key replication is good in the authentication/digital signature business process scenario.

a problem arises when the business purpose uses of the public/private key pair isn't sufficiently described ... leading to confusion (and/or the same public/private key pair are used for different business processes with possibly conflicting threat models).

dual-use digital signature vulnerability

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 26 Jul 2004 14:26:01 -0600
To: Richard Levitte - VMS Whacker <levitte@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: pgut001@xxxxxxxx, cryptography@xxxxxxxx,
sws@xxxxxxxx, astiglic@xxxxxxxx
At 02:00 PM 7/26/2004, Richard Levitte - VMS Whacker wrote:
That's all and well, but I can't see why that would be interesting to a generic, third-party CA. If you're talking about a CA within the same corporation, then I can understand, since they usually (as far as I can guess) work from a different standpoint and with different priorities.

What you describe feels to me like encryption is ill understood and placed in the hands of random individuals. If you want safety and recoverability, there's nothing like one or several backups, maybe protected with different means (different encryption, different storage media (including vaults), different keys, and so on).


I believe there was at least one large institutional effort where keys were generated, escrowed and loaded into hardware tokens and distributed. the persons were expected to use the hardware tokens for both authentication and encryption. if the hardware token failed (like if the battery died), they could get a new hardware token issued with the same keys.

the obviously needed the original keys if they had used the hardware token for encryption (of data that turned out to be laying around someplace).

however, it wasn't necessary to have escrowed keys for authentication, simply issuing a new hardware tokens with new (authentication) keys would have been sufficient (and reregistering the new public key).

here is an issue where, if they're using hardware tokens for key protection ... they really need to distinguish between encryption keys and authentication keys .... either a single hardware token with two different sets of keys ... and the token knows how to consistently differentiate their use between encryption and authentication ... or two different hardware tokens ... consistently used for the different (business) purposes.

there is a side issue with institutional delivered hardware tokens ... and if they were to replace existing shared-secret pins/passwords ... where a person might have a hundred unique shared-secrets for their various electronic relationships .... and potentially be issued at least one hardware token to be used in lieu of every pin/password ... and potentially a second hardware token for encryption only purposes (say in dongle form ... a key chain with 100-120 or dongles ... in need of medium sized ruck sack just to lug them around).

In Search of Eve - the upper boundary on Mallory

From: lynn@xxxxxxxx
Date: July 24, 2004 01:05 pm
To: Financial Cryptography
Subject: In Search of Eve - the upper boundary on Mallory
here are two separate threats ... one carried over from the real world ... and one ... somewhat unique to the internet.

in the real world ... people that are dealing with unknown entities, don't really care who they are ... they care whether they can be trusted. this is the better business bureau model. certificates for this purpose didn't really fly on the internet because almost all transactions are done with known entities ... repeat business and/or extremely well known operations. They didn't need a certificate attested to whether they could be trusted. The other five percent of the transactions are spread over millions of commercial websites ... and it was/is difficult to drum up a revenue model that would cover reputation certificates. ebay is somewhat addressing this with reputation scoring.

the other issue is that you are dealing with somebody you know .... but because the communication is thru a untrusted and possibly hostile network ... can you really be sure that it hasn't been subverted. PGP has a model that covers this .... you acquire the public key and validate with some out-of-band process. This handles all of the entities that you frequently deal with &/or know.

This is effectively what has been for some number of commercial entities called certification authorities which have had their public key preloaded in browsers (before they are shipped) .... it is the PGP model ... but the out-of-band mechanism is having the public keys preloaded by the browser manufacture.

For commercial entities .... a PGP browser could be preloaded with a better business bureau public key. The better business bureau could maintain a table of registerd & trusted commercial entities ... along with their public keys and URLs. You can perodically download the latest table from the better business burear website.

So one question ... is it easier for the general public to understand ... if instead of describing the paradigm with analogies to the certificate model .... is it easier to describe it as a PGP model where the person loads other entities public keys (i.e. their signature verification mechanism) and uses out-of-band process to guarantee that they have the correct signature verification mechanism.

It might be easier for the general public to relate to a signature and a signature verification methodology. That is much closer to what they currently expierence. Trying to get the general public to relate to a certificate description paradigm .... (including self-signed certificate description) that has a couple layers of (unecessary) indirection ... would seem to be a much harder task

In Search of Eve - the upper boundary on Mallory

Refed: **, - **, - **, - **
From: lynn@xxxxxxxx
Date: July 27, 2004 10:59 AM
To: Financial Cryptography
Subject: In Search of Eve - the upper boundary on Mallory
Long ago and far away we were asked to work with this small client/server startup that wanted to do payments on the server. In the year that we worked with them, they moved from menlo park to mountain view and changed their name from mosaic to netscape. minor references:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

out of this work came something called a payment gateway and electronic commerce. along the way we had to do various kinds of detailed due diligence on some number of the major things called certification authorities.

While the certification authorities were doing all sorts of integrity things ... it basically came down to making sure that the domain name you typed into your browser in some way related to the domain name of the server you were talking to.

This is significantly different "trust" issue from merchants taking credit card payments. For a merchant to take credit card payments, a merchant/acquiring financial institution has to take financial liability for the merchant ... and typically every transaction passes thru some processs related to that merchant financial institution before it gets to the consumers' bank.

With respect to the earlier post on this topic, we actually spent quite a bit of effort on certificates that had more meaning than whether the domain names match ... and weren't able to come up with a viable business scenario.

In theory, there is a requirement for trust for entities that have never dealt before. BBB, gov. & non-gov. licensing agencies provide some of this in the physical world.

In fact, various BBB and licensing agencies have looked at providing online, realtime trust information (as opposed to offline stale, static certificate oriented solutions) ... aka moving the paper certificates (hung on some wall) paradigm into an online 1990s paradigm ... as opposed to the PKI model that wants to preserve the pre-1990 offline paradigm with simple substitution of electronic bits for the paper.

The issue of the paper certificates in the pre-1990, real world ... was that there really wasn't a practical way of doing a realtime check with the authoritative agency issuing the certificate (hanging on the wall). To some extent, the PKI model is emulating the pre-1990, offline real world paradigm ... but substituting electronic bits for paper. However, with the emerging 1990, online world .... it is now frequently possible to go agency web sites and check realtime status.

to some extent this is the ebay model ... maintaining realtime information/history about parties active on ebay.

In Search of Eve - the upper boundary on Mallory

From: lynn@xxxxxxxx
Date: July 27, 2004 11:09 AM
To: Financial Cryptography
Subject: In Search of Eve - the upper boundary on Mallory
The comment about repeat business vis-a-vis first time business was based on paying for a trust infrastructure with something like transaction charges.

However, it turns out that something like 90-95 percent of the transactions are repeat transactions and/or with small number of extremely well known operations.

That leaves millions of commerce sites and possibly five percent (or less) of the transactions that are most in need of a trust infrastructure. So each of these millions of commerce sites are each making a couple bucks a month off their commerce sites ... and, as a result, for each of these commerce sites there isn't a very large value proposition for paying for a trust operation.

The issue isn't whether or not a trust infrastructure is required for such market segment ... but working out a value proposititon to cover the costs of a trust infrastructure.

should you trust CAs? (Re: dual-use digital signature vulnerability)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 28 Jul 2004 14:35:42 -0600
To: Adam Back <adam@xxxxxxxx>
Subject: Re: should you trust CAs? (Re: dual-use digital signature vulnerability)
Cc: Michael_Heyman@xxxxxxxx, cryptography@xxxxxxxx
At 12:09 PM 7/28/2004, Adam Back wrote:
The difference is if the CA does not generate private keys, there should be only one certificate per email address, so if two are discovered in the wild the user has a transferable proof that the CA is up-to-no-good. Ie the difference is it is detectable and provable.

If the CA in normal operation generates and keeps (or claims to delete) the user private key, then CA misbehavior is _undetectable_.

Anyway if you take the WoT view, anyone who may have a conflict of interest with the CA, or if the CA or it's employees or CPS is of dubious quality; or who may be a target of CA cooperation with law enforcement, secrete service etc would be crazy to rely on a CA. WoT is the answer so that the trust maps directly to the real world trust. (Outsourcing trust management seems like a dubious practice, which in my view is for example why banks do their own security, thank-you-very-much, and don't use 3rd party CA services).

In this view you use the CA as another link in the WoT but if you have high security requirements you do not rely much on the CA link.


in the case of SSL domain name certificates ... it may just mean that somebody has been able to hijack the domain name ... and produce enuf material that convinces the CA to issue a certificate for that domain name. recent thread in sci.crypt
https://www.garlic.com/~lynn/2004h.html#28 Convince me that SSL certificates are not a big scam

the common verification used for email address certificates (by certification authorities) ... is to send something to that email address with some sort of "secret" instructions. so the threat model is some sort of attack on email from the CA ... snarf the user's ISP/webmail password and intercept the CA verification email. (it simply falls within all the various forms of identity theft ... and probably significantly simpler than getting a fraudulent driver's license). with the defense that it is possibly another form of identity theft .... say you ever actually stumbled across such a fraudulently issued certificate .... it would probably be difficult to prove whether or not the certification authority was actually involved in any collusion. even discounting that there is no inter-CA certificate duplicate issuing verification .... there are enuf failure scenarios for public/private keys .... that somebody could even convince the same CA to issue a new certificate for the same email address (even assuming that they bothered to check)

Any TLS server key compromises?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 16 Aug 2004 13:54:45 -0600
To: Marc Branchaud <marcnarc@xxxxxxxx>
Subject: Re: Any TLS server key compromises?
Cc: cryptography@xxxxxxxx
At 02:34 PM 8/12/2004, Marc Branchaud wrote:
I've been wondering, has a TLS server (or client, for that matter) key ever actually been compromised? I don't think I've ever heard of one.

I'm thinking of two possible avenues for compromise, and ignoring insider attacks. One is through defects in the protocol itself or its implementation. The other would be through a compromise of the server host (e.g. a buffer overflow in Apache) that allows the attacker to copy the TLS server's private key from the file system.

It seems to me that in-the-wild attacks on the protocol or its implementation are unheard of.

OTOH, we hear about server break-ins all the time. However, one never hears about these break-ins leading to a compromise of the server's key.

Perhaps the server's private key isn't a really useful target? Although posession of the key makes it easy to spoof a secure server, actually doing that spoofing requires a secondary attack, like phishing or an active attack on the Internet, to redirect a user to the false server.

So have there ever been any actual TLS private key compromises (through any non-insider attack)?

If TLS private keys aren't attractive enough a target for them to be compromised even when the opportunity presents itself (as I'm assuming it has), then to what extent do these keys really need to be protected?


One of the issues is some prior implication that at least some of the SSL/TLS port knocking was helping identify sites that might be indicative of something to protect. Lets say somebody finds some really juicy financial targets using the technique.

So the server is penetrated and the attacker is presented with two files .... one with the private key .... and one with a million financial transactions ... which would they be more likely to take?

I would assert that the million financial transactions file .... yield possibly couple hundred thousand accounts numbers that could then be used directly in fraudulent transactions. The SSL/TLS private key just says that you have to put in some evesdropper in on the server's SSL/TLS sessions, decrypt the traffic and decide what it means. While it may be of some academic interest ... it would seem that letting the server keep on doing all that work for you ... and just harvesting the results ..... represents a lot bigger return for effort.

Part of the issue is that the threat model for server file exploit is frequently the same for the real data "at rest" and the private key file (which is just protecting the real data while in transit) ... the actual, real data can represent a lot higher immediate fraud potential.

So lets say the attacker does take both files for the fun of it .... but likely won't get around to any SSL/TLS evesdropping attacks until exhausting all the other financial fraud possibilities (from already having a huge number of account numbers). Even if they eventually exhaust any current crop of fraudulently harvested account numbers ... they will likely try the same attack on another server ... before they possibly decide that SSL/TSL evesdropping attacks are worth the effort.

It is possible, the SSL/TSL private key file might be more attractive target in non-financial sector circles (evesdropping for the sake of evesdropping .... possibly for other than direct financial incentive).

You would probably start hearing about the client keylogger exploits including any client private key file .... if client keys started being used for any significant purposes .... aka current client keylogger exploits are able to authenticate directly just from the pin/password key capture. any migration to private key operations would mean that the client keylogger attacks would also need the private key file (with the pin/password capture then being used to decrypt the private key file in order to use the private key for authentication).

RPOW - Reusable Proofs of Work

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 16 Aug 2004 16:31:58 -0600
To: "R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: RPOW - Reusable Proofs of Work
Cc: cryptography@xxxxxxxx
At 12:36 PM 8/15/2004, R. A. Hettinga wrote:
The new concept in the server is the security model. The RPOW server is running on a high-security processor card, the IBM 4758 Secure Cryptographic Coprocessor, validated to FIPS-140 level 4. This card has the capability to deliver a signed attestation of the software configuration on the board, which any (sufficiently motivated) user can verify against the published source code of the system. This lets everyone see that the system has no back doors and will only create RPOW tokens when supplied with POW/RPOW tokens of equal value.

I got hit with exploits on 4758 cards ... in thread in sci.crypt
https://www.garlic.com/~lynn/2004j.html#2

RPOW - Reusable Proofs of Work

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 16 Aug 2004 16:50:13 -0600
To: "R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: RPOW - Reusable Proofs of Work
Cc: cryptography@xxxxxxxx
At 12:36 PM 8/15/2004, R. A. Hettinga wrote:
This is what creates trust in RPOWs as actually embodying their claimed values, the knowledge that they were in fact created based on an equal value POW (hashcash) token.

the issue in the yes card exploit is that you migrate the financial business rules out into hardware tokens (of any kind) and then do peer-to-peer operations between tokens.

the threat model is you attack the belief in a valid hardware token ... once you have that you have the mechanism for creating counterfeit tokens that can convince other tokens that they are valid. These counterfeit tokens don't tell the truth ... they are programmed to say whatever will convince other tokens that can be trusted.

and as per previous post ... i got hit in a sci.crypt thread with the claim that even 4758 can be successfully attacked.

misc. posts discussing yes card token attacks that 1) result in being able to fabricate counterfeits 2) which are acceptable in offline, peer-to-peer operations:
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
https://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
https://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
https://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
https://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

RFC 3833 Threat analysis of the domain name system (DNS)

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: cryptography@xxxxxxxx
Subject: RFC 3833 Threat analysis of the domain name system (DNS)
Date: Wed, 25 Aug 2004 16:13:08 -0600
as always ... can go to
https://www.garlic.com/~lynn/rfcietff.htm

and either scroll down the summary page to the 3833 summary and then retrieve the actual RFC by clicking on the ".txt=nnnn" field.

In this case it is also possible to click on Term (term->RFC#) in the RFCs listed by section ... and then click on "DNSSEC" in the Acronym fastpath section at the top. That brings up the DNSSEC RFCs. ... where DNSSEC (and/or domain name security) appeared somewhere in the title or abstract.

as a side note, I've just done about everything possible that I can do with scanning actual RFCs for references. I did a pass ... where I created a list of all RFCs ... where the scan didn't produce RFC numbers from a reference section ... and then scanned those RFCs for anything that looked like there might be a RFC number anywhere in the body. Then I manually examined that list of RFCs for how they formated/called the references section. somewhat more detailed discussion of the references & md5 stuff:

https://www.garlic.com/~lynn/2004k.html#6
RFC 3833
Title:      Threat Analysis of the Domain Name System (DNS)
Author(s):  D. Atkins, R. Austein
Status:     Informational
Date:       August 2004
Mailbox:    derek@xxxxxxxx, sra@xxxxxxxx
Pages:      16
Characters: 39303
Updates/Obsoletes/SeeAlso:    None
I-D Tag:    draft-ietf-dnsext-dns-threats-07.txt
URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3833.txt
Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats.

[anonsec] Re: potential new IETF WG on anonymous IPSec

Refed: **, - **, - **
Date: Mon, 13 Sep 2004 13:16:17 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: [anonsec] Re: potential new IETF WG on anonymous IPSec
Cc: cryptography@xxxxxxxx, eugen@xxxxxxxx
At 11:43 AM 9/11/2004, Peter Gutmann wrote:
So in other words it's the same baby-duck security model that's been quite successfully used by SSH for about a decade, is also used in some SSL implementations that don't just blindly trust anything with a certificate (particularly popular with STARTTLS-enabled MTAs/MUAs where you don't want to bother with CA-issued certs), and is even used in various X.509 applications (via "certificate fingerprints"), although the X.509 folks don't like to admit that because it implies that a known-good cert fingerprint is more reliable than a CA :-).

i've referred to it as identity agnostic ... as opposed to anonymous ... even with public key use. the scenario is that the original identity x.509 certificates created huge privacy issues.

the current credit card scenario, it carries a name ... in theory so that the merchant or point-of-sale can cross-check the name against additional forms of identification .... as a means of authentication (where the merchant is sort of a stand-in agent for the consumer's financial institution .... even tho the merchant and the consumer's financial institution may have significantly different and possibly opposing interests). in effect it is transforming something that should be purely an authentication operation (is the entity entitled to perform a transaction for the account) into a much more difficult (and privacy invasive) identification operation.

the x9.59 scenario ....
https://www.garlic.com/~lynn/x959.html#x959
is that the transaction is simply authenticated with a digital signature that the merchant passes thru to the consumer's financial institution. the consumer financial institution verifies the digital signature with public key on file for that account. the verification of the digital signature implies some form of something you have authentication (implies that you uniquely have the corresponding private key).

it becomes a straight-forward authentication operation and identity agnostic ... w/o the horrible identity and privacy invasive that can accompany a x.509 identity certificate.

while it may be possible for various agents to associate the authentication operation w/identities .... the operations themselves, at least don't carry the possibly mandatory identity information & privacy invasive information that can be found in identity x.509 certificates.

public-key: the wrong model for email?

Date: Wed, 15 Sep 2004 18:54:11 -0600
To: Ed Gerck <egerck@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: public-key: the wrong model for email?
Cc: <cryptography@xxxxxxxx>
At 12:39 PM 9/15/2004, Ed Gerck wrote:
[1] Public-key cryptography gives the impression that email message security can be achieved quite simply. The public-key can be distributed at will, no need for secrecy, and anyone can receive private and secure messages. The same procedure being applied to each side, sender and receiver, both could immediately engage in private and secure communication.

there are (at least) 2-3 characteristics of various public key systems
  1. the public key doesn't have to be kept confidential as part of the distribution
  2. you don't need a unique key for every unique security &/or business domain
  3. other parties can attest to any bindings between the public key and other characteristics
however, while the fact that public key secrecy isn't required (vis-a-vis secret keys) ... and possibly enables one or more of the mentioned characteristics, public key operation doesn't mandate all such characteristics be mandatory for the use of public keys.

PGP allows that a relying party vet a public key with the key owner and/or vet the key with one or more others (web-of-trust)

note that while public key alleviates the requirement that a key be distributed with secrecy ... it doesn't eliminate the requirement that the public key have some trust characteristic associated (i.e. secrecy will tend to include some trust, but elimination of secrecy doesn't eliminate the requirement for trust).

so an infrastructure analogy to physical mail for public key .... is that public key becomes the trusted address for the recipient. in the physical world ... to send some mail ... you need a trusted mailing address for the recipient ... you need to have acquired that address in some manner and furthermore have some trust that it is the correct address. so lets assume that some number of equivalent mechanisms exist for public keys. it so happens that the encryption of the contents with the public key and the addressing of the contents with that same public key .... has some associated trusted infrastructure that delivers the package to the correct recipient.

lets say that instead of having personal zip-codes and personal cell-phone numbers (that you take with you regardless of the service and/or physical location)... that can reach you regardless of where you happen to be in the world .... the "number" that can be guaranteed to reach you, also happens to have the characteristics of a public key.

so public key mapping to entity infrastructures take on similar characteristics as personal (physical) mailing addresses and/or personal cell-phone numbers ... and then you have trusted infrastructures (usps, telephone companies, gov. posts) that can be relied on to make the connection to the appropriate recipient .... which then approximates a public key paradigm mapping to existing physical world paradigms.

in the current physical world infrastructure, the publication &/or distribution of addresses are relatively low-cost (&/or free) operations with the infrastructures making their real money off the delivery ... as opposed to the publication.

translated to the internet paradigm .... everybody has a public key (in much the same way that everybody can have a personal cellphone number that may reach them regardless of where they are in the world). the public key is registered in something like the domain name infrastructure which then is able to figure out how to find you in the world (in manner similar to how personal cellphone number can find you anywhere in the world).

it isn't necessary that public key paradigms have to be the wrong model for email .... it is that the various existing economic models for making money off of public key infrastructures may be inconsistent with normal expected business operations. however, there is nothing intrinsic to public keys that mandate they are tied to existing public key infrastructure economic models.

public-key: the wrong model for email?

Date: Thu, 16 Sep 2004 10:42:37 -0600
To: Ed Gerck <egerck@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: public-key: the wrong model for email?
Cc: <cryptography@xxxxxxxx>
At 11:19 PM 9/15/2004, Ed Gerck wrote:
Yes, PKC provides a workable solution for key distribution... when you look at servers. For email, the PKC solution is not workable (hasn't been) and gives a false impression of security. For example, the sender has no way of knowing if the recipient's key is weak (in spite of its length) or has some "key-access" feature. Nonetheless, the sender has to use that key.

the issue then is what level do you trust the recipient, what is the threat model, and what are the countermeasures.

if there is a general trust issue with the recipient (not just their key generating capability) ... then a classified document compromise could happen after it has been transmitted. you may have to do a complete audit & background check of the recipient before any distribution of classified document.

if the threat model is purely the document transmission, and you worry only about the recipient's key generating capability being up to the task of protecting the document transmission ... but you otherwise aren't worried about other trust issues with the recipient ... then go for 3rd party secure transmission service ... say where the encrypted package is delivered to the recipient and the recipient has to do some sort of real-time retrieval from the 3rd party of the package encryption key.

in the physical world ... there still could be the issue that the delivery address for the recipient (to be used by the 3rd party delivery service) might not be trusted.

part of the problem with introducing trust issues involving any specific recipient issue starts a real slippery slope .... since the security of the system is all of the infrastructure .... and just addressing a single recipient trust issue (like key generation strength) .... still leaves open all sorts of other recipient trust issues.

say you have 3rd party encryption and secure delivery ... with the possibility that the electronic package might be evesdropped (copied but not decoded). the issue then is how does the 3rd party know that the correct recipient is the only one that obtains the correct decryption key. there has to be some trust at some point that the correct recipient and only the correct recipient can decode any encrypted electronic package. at some point there has to be some flavor of trusting some sort of recipient authentication mechanism.

either the sender has it before hand (like the recipient's public key) or there is some sort of post-transmission authentication of the recipient. eliminating the requirement for strong authentication of the recipient before the transmission doesn't really eliminate the problem, it just moves it to some point.

public-key: the wrong model for email?

Date: Fri, 17 Sep 2004 09:11:05 -0600
To: Adam Shostack <adam@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: public-key: the wrong model for email?
Cc: Ed Gerck <egerck@xxxxxxxx>, <cryptography@xxxxxxxx>
At 05:35 PM 9/16/2004, Adam Shostack wrote:
Generate a key for "unknown-recipient@xxxxxxxx" encrypt mail to Bob to that key. When Bob shows up, decrypt and send over ssl.

note there is still the issue of knowing it is bob ... whether before the "transmission" or after the "transmission" .... and, in fact, the "transmission" itself is somewhat arbitrary.

in the physical world ... the base point is that the sender pays to physically transmit something. there is threat model of taking physical possession of whatever is being transmitted. they then pay extra for countermeasures wrong person taking physical possession. they also pay extra for extra care in delivery to the correct person.

the current electronic world ... the base point is that the sender doesn't actually pay per transmission. with encryption, the threat model is changed to possession of the unencrypted information. encryption (shared-secret or digital signatures) is also used to help with the issue of "delivery" to the correct person (although the convention is converted to the correct person decrypts the data).

so what is the difference between the sender setting up facility so that "when bob shows up" .... bob gets a decrypted version .... and say sending a version to some trusted 3rd party that is encrypted with the 3rd party's key ... and direction to only let bob have it when bob shows up. how does the 3rd party know its bob ... any better than the originating sender? note also in standard ssl ... the recipient generates a random symmetric key and sends it to the server, encrypted with the server's public key. there is nothing about how the server knows that the bob making the contact ... and the bob that is suppose to receive the information .... is the same entity.

so the 3rd party keeps the pre-transmitted encrypted stuff with directions to only give it to any entity that shows the magic something (the movie stuff about tearing a bill in half and the person needs to have the appropriate torn half). the 3rd party holds it until bob contacts the sender and gets the magic something ... which they can give to the 3rd party. given the nature of electronic transmission ... is that really substantially different than the sender waiting until bob contacts them before doing the original transmission.

if it is purely electronic world ... how does the sender get the necessary information to the correct bob ... so that the correct bob can give the stuff to the 3rd party ... to proove that they are the correct bob.

so possibly the only distinction ... is that the email communication between bob and the sender is non-real-time ... and the SSL communication is considered possibly real-time .... so the scenario isn't actually the information being transmitted between the sender and bob that is the issue ... it is possibly the mechanics of real-time vis-a-vis non-realtime?

so the sender at some point has to trust bob's authentication information (whether directly and/or outsourced to 3rd party) ... say digital signature public key and may or may not trust that same key for encryption.

common pgp flow ... which effectively is the same as ssl .... same process steps ... but possibly not in real time. sender looks up in some directory the contact information for bob, this directory is trusted to map the contact process for bob to bob .... the directory may or may not also provide some authentication information for bob. if the sender doesn't have authentication information for bob ... they send message to bob requesting authentication information. when they get that back, they vet the authentication information before using it to make sure it is actually for bob. so now they have a process which has some assurance of contacting bob and some assurance that bob can be authenticated. this is pretty much true whether the actual sender is responsible for the steps or has been outsourced to some 3rd party.

now the issue is wether or not the authentication information is also trusted to securely protect the classified information during transmission (aka public key). possible scenario if sender requires different encryption keys from authentication information:
  1. sender sends message to bob saying classifed document is waiting. bob generates secret key, digitally signs it, encrypts it with the senders public key and returns it to the sender. this could be all email exchange ... or possibly combination of email and ssl .... it could also be directly with the sender or a 3rd party agent on the sender's behalf.
  2. the sender decrypts bob's message, validates the digital signature, encrypts the classified information with bob's secret key and sends the information to bob. the sender's process can be email or ssl ... and can either directly be the sender ... or a 3rd party acting on the sender's behalf.
for efficiency purposes .... the acquisition of bob's authentication information and possible encryption key might be collapsed into single round trip. sender (or 3rd party on sender's behalf) send bob a message that they need both bob's authentication information .... as well as a digitally signed, randomly generated secret key ... which is encrypted with the supplied public key. the sender/3rd party then has to vet bob's authentication information .... before using the randomly generated secret key. again, the exchange could be purely non-real-time email .... or combination of email and real-time ssl.

sort of practical issues:

given that the electronic paradigm have enuf differences from the physical world sending model (i.e. sender doesn't pay in the base case) .... can sender's be induced to pay 3rd party to outsource some of the operations?

given that the there are some number of other vulnerabilities and exploits in the overall infrastructure .... is the treat model specifically to trusting bob's public key for both authentication and confidential transmission .... sufficient to impose the extra processes (and/or convince sender's that they need to pay extra money for outsourcing to 3rd parties).

since the paradigm issue of securely transmitted has changed from secure physical movement to safe encryption .... a 3rd party may only have to provide a business of assuring recipients' public keys for "safe" transmission (as opposed to actually doing the transmission). everybody gets to generate their own public/private key pair for authentication. the same key pair is not used for both authentication and encryption. people may also generate their own encryption key pair.

senders either trust a recipient's encryption key pair ... or they don't. if the sender doesn't trust a recipient's encryption key pair .... they ask for a encryption public key that has been issued by a trusted 3rd party ... and for which the 3rd party is willing to attest to. there is an issue of how the issued private key has gotten to the recipient ... but that isn't a whole lot of difference than the process of a recipient exchanging a real secret key for transmission. there is an issue of whether or not the recipient has continued to protect the encryption private key .... but that isn't a whole lot difference than whether or not the recipient has the facility to protect the unencrypted classified document (once they receive it).

the physical world has the sender outsourcing and paying for the actual secure physical movement .... and some assurance that it only goes to the intended recipient. translated to the electronic world ... the paradigm has been changed to the use of encryption to make sure wrong people don't have the unencrypted version ... and various kinds of authentication processes. so the critical processes has changed not from the actual movement of the data ... but the encryption process "gatekeepers" .... aka the integrity and management of keys used for authentication and decryption. so rather than focus on the actual electronic transmission processes .... focus on the issues related to the keys.

public-key: the wrong model for email?

Date: Sat, 18 Sep 2004 10:19:20 -0600
To: Ed Gerck <egerck@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: public-key: the wrong model for email?
Cc: <cryptography@xxxxxxxx>
At 12:53 PM 9/16/2004, Ed Gerck wrote:
If the recipient cannot in good faith detect a key-access ware, or a GAK-ware, or a Trojan, or a bug, why would a complete background check of the recipient help?

a "complete audit and background check" ... would include an audit of the recipient ... not just the recipient person .... but the recipient ... as in the recipient operation.

so given sufficient sender concern, checking might be similar to something that the federal reserve has specified for a fedwire terminal .... although the announcement about allowing fedwire access via the internet has raised some eyebrows. i'm sure that such things don't happen .... but could all the stuff about swift providing internet-oriented services been some motivation?

the issue for the sender is that they could be concerned about a number of different possible vulnerabilities ... and complete audit and background check would be to try and cover all the bases ... aka the leakage of a classified document wouldn't solely be restricted to technical subversion.

EMV cards as identity cards

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 09/20/2004 10:06 AM
To: Anders Rundgren <anders.rundgren@xxxx>
cc: <internet-payments@xxxxxxxx>
Subject: Re: EMV cards as identity cards
this is similar to the problem with identity x.509 certificates that EU financial institutions identified in the early 90s .... and resulted in EU (as well as other) financial institutions migrating to relying-party-only certificates in the mid-90s (i.e. effectively containing only an account number and a public key).

also in the mid-90s ... the EU had some dictate that retail point-of-sale electronic transactions should be as anonymous as cash. there was then some push to have "names" taken off of payment cards for point-of-sale transactions .... leaving only the PAN (not just chip-cards ... but all retail, point-of-sale cards).

of course, the relying-party-only certificates with just PAN and public key .... resulted in mainly online transactions; however it was trivial to show that relying-party-only certificates are redundant and superfluous in online transactions .... since the relying-party will also be the issuing party and therefor have the public key onfile at the relying/issuing party. a traditional ISO 8583 payment transactions (upgraded to include an appended digital signature) coming into a issuing/relying party ... will have a PAN ... looking up the account number ... and being able to retrieve the public key from the account record.

this makes the public key carried in an appended relying-party-only certificate, redundant and superfluous .... since the only other information in the relying-party-only certificate is the PAN ... which is carried in the 8583 transaction itself, this makes the whole relying-party-only certificate also redundant and superfluous.

the other issue with redundant and superfluous relying-party-only certificates that various of the payment pilots of the mid-90s that had relying-party-only certificates .... was that the typical redundant and superfluous relying-party-only certificate could be approximately two oders of magnitude (100 hundred times) larger than the base 8583 payment transaction itself. the result was an enormous payload bloat (of 100 times) to append a redundant and superfluous relying-party-only certificate to a typical 8583 payment transaction

similar thread in this mailing list earlier this spring:
https://www.garlic.com/~lynn/aadsm17.htm#12 A combined EMV and ID card
https://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card

at 9/17/2004 10:50 pm, anders wrote:
In Sweden banks are combining the EMV payment application(s) with a separate identity application using PKI. The reasons are obvious, one card does it all.

The drawback is that the card holder's identity including social security numbers etc. is available for any merchant terminal to read if they want, as the public keys (certificates) are not protected by PIN codes etc. If they were protected the card would be incompatible with existing software and become harder to use so that is not an option.

I would like to hear if anybody have heard of similar efforts in other parts of the world.

Anders Rundgren


x9.99 privacy note

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/20/2004 10:45 AM
To: <internet-payments@xxxxxxxx>
Subject: x9.99 privacy note
x9.99 privacy impact assesement standard has been approved
http://www.x9.org
and the document should show up on the ansi electronic store before too long

and the work item has been approved for iso tc68
https://web.archive.org/web/20021119011718/http://www.tc68.org/
https://web.archive.org/web/20030425064722/http://www.iso.ch/iso/en/stdsdevelopment/tclist/TechnicalCommitteeDetailPage.TechnicalCommitteeDetail?TC=68

there is some slightly related information .... i have a start at a merged privacy glossary and taxonomy at
https://www.garlic.com/~lynn/index.html#glosnote

EMV cards as identity cards

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/20/2004 02:11 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: <internet-payments@xxxxxxxx>, Safecode <safecode@xxxxxxxx>
Subject: Re: EMV cards as identity cards
on of the issues in the account/identity fraud scenarios is that just knowing the PAN .... allows fraudulent transactions to be performed. you start to see things like harvesting of merchant transaction files that provide PANs for fraudulent transactions. recent studies have indicated that possible at least 77 percent of such harvesting involves insiders.

part of the scenario is the security versus risk discussed in this posting about merchant transaction file harvesting ans security proportional to risk:
https://www.garlic.com/~lynn/2001h.html#61

one of the requirements given the x9a10 working group for x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payments. the resulting x9.59 standard
https://www.garlic.com/~lynn/x959.html#x959

uses digital signature to authenticate retail transactions (regardless of kind, including iso 8583 payment transactions) but doesn't mandate the horrendous payload bloat of attaching a redundant and superfluous relying-party-only certificate.

x9.59 also specifies that account numbers that are used in x9.59 transactions can not be used in non-authenticated transactions. the result is that it is no longer possible to perform fraudulent payment transactions just by learning an account number. the scenario then is that if it is no longer possible to perform fraudulent transactions by harvesting (x9.59) account numbers from merchant transaction files .... then it is no longer necessary to maintain such high security infrastructures to prevent crooks from acquiring knowledge of account numbers.

we've referred to this being privacy or identity agnostic .... as opposed to truely anonymous. there is still an account number floating around ... but typically has no other identifying information ... unless somebody gets a court order to acquire the information from your financial institution. misc references to privacy, identity, x9.59, etc
https://www.garlic.com/~lynn/subpubkey.html#privacy

misc. past postings mentioning privacy/identity agnostic:
https://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
https://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aepay7.htm#liberty Network Identity Alliance -- Liberty Alliance Project
https://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias
https://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/aadsm18.htm#22 [anonsec] Re: potential new IETF WG on anonymous IPSec

at 9/18/2004 11:32 pm anders wrote:
Paulo I may have lost the safecode stuff.

I have no detailed description of EMV but that is probably easy to get on the net.

But I essentially described a multi-application smart card which could hold a credit-card function, a purse and in this case also an identity function using PKI.

Since the card does not have a display or keyboard etc. there is no way to select what resource the card reading app is to use. It is therefore assumed that this is "hardcoded" into applications or that applications offer this selection. However, you cannot do a selection without having parts of the available resources accessible. In the case of the ID-application it is actually your full identity!

To allow any merchant to monitor a card holder's identity is in to some extent already possible due to the PAN code, but to *extend* this "feature" seems to clearly be a step in the wrong direction.


Academics locked out by tight visa controls

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 20 Sep 2004 16:07:55 -0600
To: John Kelsey <kelsey.j@xxxxxxxx>
Subject: Re: Academics locked out by tight visa controls
Cc: <rah@xxxxxxxx>, cryptography@xxxxxxxx
At 08:03 AM 9/20/2004, John Kelsey wrote:
I guess I've been surprised this issue hasn't seen a lot more discussion. It takes nothing more than to look at the names of the people doing PhDs and postdocs in any technical field to figure out that a lot of them are at least of Chinese, Indian, Arab, Iranian, Russian, etc., ancestry. And only a little more time to find out that a lot of them are not citizens, and have a lot of hassles with respect to living and working here. What do you suppose happens to the US lead in high-tech, when we *stop* drawing in some large fraction of the smartest, hardest-working thousandth of a percent of mankind?

in '94 there was report (possibly sjmn?) that said at least half of all cal. univ. tech. PHDs were awarded to foreign born. during some of the tech green card discussions in the late '90s ... it was pointed out that the internet boom (bubble) was heavily dependent on all these foreign born .... since there was hardly enuf born in the usa to meet the demand.

in the late 90s there were some reports that many of these graduates had their education paid by their gov. with directions to enter an us company in strategic high tech areas for 4-8 years .... and then return home as tech transfer effort. i was told in the late 90s about one optical computing group in a high tech operation .... where all members of the group fell into this category (foreign born with obligation to return home after some period).

another complicating factor competing for resources during the late 90s high-tech, internet boom (bubble?) period was the significant resource requirement for y2k remediation efforts.

nsf had recent study on part of this
http://www.nsf.gov/sbe/srs/infbrief/ib.htm

graduate enrollment in science and engineering fields reaches new peak; 1st time enrollment of foreign students drops
http://www.nsf.gov/sbe/srs/infbrief/nsf04326/start.htm

EMV cards as identity cards

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/21/2004 09:31 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: <internet-payments@xxxxxxxx>, <safecode@xxxxxxxx>
Subject: Re: EMV cards as identity cards
i have pointed out in multiple threads and numerous times (a number of times when you have raised this or similar question in the past) .... that there has been some history of x.509 identity certificates from the early 90s and that the in the mid-90s, many financial institutions around the world retrenched to relying-party-only certificates .... because of the enormous privacy and liability issues associated with the x.509 identity certificates.

I was at a presentation by one of the large german banks at the 1998 21st nissc conference in DC ... on the enormous privacy and liability issues associated with x.509 identity certificates and the requirement for relying-party-only certificates (effectively only containing an account number and public key).

There were payment transaction designs and deployments from the mid-90s that also used relying-party-only certificates and had made some reference to the enormous privacy and liability issues associated with x.509 identity certificates.

lots of past postings on relying-party-only certificates:
https://www.garlic.com/~lynn/subpubkey.html#rpo

the issue that i've also pointed out multiple times in the past is that for online transactions involving replying-party-only certificates, that the relying-party-only certificates can typically be shown to be redundant and superfluous ... since the relying-party is the issuing party ... and therefor already has a registered copy of the public key (typically stored in an account record which will be referenced as part of any online transaction).

the ancillary issue from some of the payment transactions from the mid-90s using relying-party-only certificates for online iso 8583 payment transactions was that there was enormous payload bloat with even various relying-party-only certificates being approximately two orders of magnitude larger in size than typical base iso 8583 transaction.

there has also been some sporadic discussions that sometimes there is confusion between identification and authentication and that there are times that identification has been specified when authentication would have been sufficient.

at 9/21/2004 12:27 am, anders wrote:

Exactly what are you addressing here???
1. That EMV is a bad idea since it (optionally) uses PKI?
Could very well be so but EMV is also an off-line thing as the EMV founders incorrectly thought that not many countries could afford broadband! Regardless how right of wrong this assumption may be, those who actually are prepared to convert to accepting chip-cards, probably have broadband as well. That is, a core EMV idea is indeed ill-founded!

2. That ID certificates are redundant?
As ID certificates is an FI add-on service to be used by thousands of independent e-gov relying parties using a common national identity scheme, there is no viable alternative to PKI except using a gateway approach which is fairly much the same trust wise. The difference is that some people do not believe that gateways can sign but schemes running in Norway shows that this is piece of cake. At least technically!

Anders


EMV cards as identity cards

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/22/2004 10:11 AM
To :<internet-payments@xxxxxxxx>,
cc: <anders.rundgren@xxxxxxxx>, <safecode@xxxxxxxx>
Subject: Re: EMV cards as identity cards
possibly unrelated, random news, privacy related URL distributed today about eu commission and the eu data protection act
http://iccheshireonline.icnetwork.co.uk/0100news/0200businessfarmingnews/tm_objectid=14663715&method=full&siteid=50061&headline=raid-threats-to-city-firms-name_page.html

there is also an issue with regard to what it means to "sign" .... digital signatures as in authentication .... can be hardware tokens, portals, etc. .... i.e. "signing" as part of some type of three factor authentication:
https://www.garlic.com/~lynn/subintegrity.html#3factor if a portal produces a digital signature, then a relying party might imfer that there was some form of something you know authentication since the portal might be designed to only perform a digital signature when provided with some form of password.

if a hardware token produces a digital signature, then a relying party might possibly infer both something you know and something you have authentication ... assuming that a person holds the hardware token and the hardware token requires a pin or password to operate

authentication definitions would, in no way, preclude portals performing digital signatures .... since it all comes down to is what a relying party may infer when they encounter a digital signature.

problems could crop up though if people were to confuse such digital signatures with legal signatures (as opposed to being able to just infer some form of authentication).

in the crypto mailing list there was an extended discussion about infrastructure vulnerability when the same key pairs might be used for both authentication events as well as in conjunction with legal signature operations:
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)

semi-related to x9.99 privacy standard being passed (and should show up at the ansi e-store shortly) and the new privacy work item being approved for iso tc68 ... i also recently got an email notice that iso sc6 has approved a new work item for the finread terminal

there was a related discussion in the sci.crypt newsgroup regarding some of the requirements for legal signature (with some relationship to feature/function in finread terminal, but happened to wander around and cover a somewhat broader range of characteristics):
https://www.garlic.com/~lynn/2004h.html#48 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#50 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#52 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#53 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#54 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#55 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#56 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#57 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#59 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#2 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#4 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#9 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#10 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#11 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#12 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#13 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#14 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#15 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#19 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#20 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#22 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#23 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#25 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#27 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#0 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#1 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#3 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#8 New Method for Authenticated Public Key Exchange without Digital Certificates

An interesting "new" computer security problem

Date: Mon, 27 Sep 2004 12:58:31 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An interesting "new" computer security problem
Cc: cryptography@xxxxxxxx
note that was being done with virtual machines in the 60s .... well before the orange book

there were also a number of commercial time-sharing companies offering services based on virtual machine technology where possibly mutually antagonistic clients were using the services.

we had a service that had some of the most sensitive corporate secrets there were .... on the same machine with all sorts of BU, MIT, and harvard students.

random past references to some of the in-house as well as commerical (virtual machine based) time-sharing services from the 60s & 70s:
https://www.garlic.com/~lynn/submain.html#timeshare

At 11:03 PM 9/24/2004, Peter Gutmann wrote:
A few days ago I was chatting with some people working on a government IT project who had a rather complex security problem that they needed help with. They have a large number of users with Windows dumb terminals (think Xterms but for Windows) connected to a central ASP server, which runs various mutually untrusted apps from different vendors. Their problem was that they needed a means of securing the individual apps from each other.

I told them that they were in luck, and this exact problem had already been addressed before. I'd drop off the detailed technical specs for the solution when I next saw them, they could recognise it by its bright orange cover.

Peter.

(Actually it wasn't quite that simple and easily solveable: The ASP server is untrusted as well, it just acts as a middleman for back-ends located at various locations, and only the back-ends are trusted. I figured giving them the Orange Book would be easier than trying to explain that they had an unsolveable problem on their hands).


An interesting "new" computer security problem

Date: Mon, 27 Sep 2004 13:51:36 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An interesting "new" computer security problem
Cc: cryptography@xxxxxxxx
for instance ... it wasn't exactly hidden that a certain gov. TLA was very active in a particular vendor's user group organization .... and in fact, had somebody that chaired some of the committees from time-to-time.

look for installation code CAD in these virtual machine archives (mostly from the 70s & 80s)
http://vm.marist.edu/~vmshare/

here is another organization from the late '70s (rather than the late '60s):
https://www.garlic.com/~lynn/2001m.html#15

Credit card leaks continue at a furious pace

Refed: **, - **, - **, - **
From: Lynn Wheeler
Subject: Credit card leaks continue at a furious pace
To: <internet-payments@xxxxxxxx>
Date: Tue, 28 Sep 2004 09:09:18 -0600
Credit card leaks continue at furious pace
Security firm claims 120 million accounts compromised this year
http://www.msnbc.msn.com/id/6030057/
"We are writing you today to let you know that Visa recently informed us of an unauthorized network intrusion," says a note sent earlier this month by Washington Mutual bank to an undisclosed number of consumers. "This network breach affects the security of your Washington Mutual ATM/Visa Check Card."

... snip ...

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

some mention of not being able to perform fraudulent transaction just by knowing a (x9.59) pan ... in this long winded discussion about dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#6

Phishing losses total $500 million - Nacha

From: Lynn Wheeler
Date: 09/29/2004 07:55 PM
To: <internet-payments@lxxxxxxxx>
Subject: Phishing losses total $500 million - Nacha
Phishing losses total $500 million - Nacha
http://www.finextra.com/fullstory.asp?id=12568
US payments association Nacha estimates the total monetary losses to victims of phishing incidents nationwide may run as high as $500 million.

... snip ...

Fake Companies, real money; elaborate con wrings cash out of stolen credit cards

From: Lynn Wheeler
Date: 10/08/2004 03:12 PM
To: internet-payments <internet-payments@ls.fstc.org>
Subject: Fake Companies, real money; elaborate con wrings cash out of stolen credit cards
Fake companies, real money, Elaborate con wrings cash out of stolen credit cards
http://www.msnbc.msn.com/id/6175738/
T-Data, a small New-York based software company, doesn't take credit cards -- never has in its 20-year history. But a few weeks ago, owner Jeff Duhl found himself looking over $15,000 worth of credit card charges seemingly accepted by his store.

... snip ...

... and a copy more while i'm at it ...

Corporate Identity Theft on the Rise
http://it.slashdot.org/it/04/10/08/1333219.shtml?tid=172&tid=187
"As millions of Americans lose their identities to online and offline thieves, a new kind of crime has been cooked up by the criminals who are not bothering with doing pesky credit card charges."

.. snip ...

Top reason for identity theft: stolen wallet
http://www.itfacts.biz/index.php?id=P1077
Exactly 15% of US consumers have been victims of identity theft, and 33% know a family or friend who has been, according to a new survey from InsightExpress. A full 85% of respondents are concerned that identity theft could happen to them. Most fear their identities could be taken through a stolen wallet, and large percentages fear theft through the Internet or stolen mail. Overall, 37% felt online purchasing poses the greatest threat, followed by telephone purchases (34%) and in-person purchases (10%).

... snip ...

How to store the car-valued bearer bond? (was Financial identity...)

Date: Sat, 23 Oct 2004 13:51:44 -0600
To: Ian Grigg <iang@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: How to store the car-valued bearer bond? (was Financial identity...)
Cc: Aaron Whitehouse <lists@xxxxxxxx>, cryptography@xxxxxxxx
somewhat the original design point for the EU stored-value smartcards was an environment with poor, non-existent, and/or extremely expensive online connectivity.

by contrast during the 90s, there was a big growth in stored-value cards in the US that involved online transactions and where the stored-value card was effectively just an authentication token.

in effect, the cost/benefit trade-off of the EU-based chips .... was the cost of the chips enabling distributed offline transactions against the poor, non-existent, and/or extremely expensive online connectivity.

in the intervening years .... effectively a couple of things have happened

1) growing world-wide ubiquitous online connectivity (significantly mitigating being forced into having to do offline transactions anywhere in the world)

2) increasing sophistication and ease of being able to counterfeit both magnetic stripe authentication tokens ... as well as attacks on the offline infrastructures where it is assumed that business rules have been embedded in stored-value smartcard tokens in order to enable offline transactions.

so now there is tendency for pushing chip tokens to address the ease that magnetic stripe authentication tokens are being counterfeited ... but that is quite orthogonal to the EU oriented stored value smartcards targeted at enabling offline transactions (although sometimes the two different objectives and solutions get confused ... because they both can involve hardware chip cards .... even tho there is vast difference in using a hardware chip card for pure authentication vis-a-vis having required business rules and logic in hardware chip card for performing offline transactions).

Financial identity is *dangerous*? (was re: Fake companies, real money)

Date: Thu, 28 Oct 2004 12:21:32 -0600
To: Ian Grigg <iang@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Financial identity is *dangerous*? (was re: Fake companies, real money)
Cc: Alan Barrett <apb@xxxxxxxx>, cryptography@xxxxxxxx
At 03:31 PM 10/25/2004, Ian Grigg wrote:
:-)

It should be obvious. But it's not. A few billions of investment in smart cards says that it is anything but obvious.

To be fair, the smart card investments I've been familiar with have been at least very well aware of the problem. It didn't stop them proceeding with papering over the symptoms, when they should have gone for the underlying causes.
iang


my claim about the paradigm is that during the 80s, there was start of lot of investment by all sorts of parties into smartcards ... targeted for the portable computing market niche ... where the state of the art would allow relatively powerful computing and memory in such chips ... but the technology didn't exist for portable input/output technology .... as a result there also had to be ISO international standards for the input/output stations that would interoperate with the smartcards. that market niche started to disappear in the early 90s with the appearance of portable input/output technology associated with cellphones and PDAs. by this time, at least several billion dollars had been invested in the technology.

somewhat to recoup (at least some portion of) the investment, there has been some searching for alternative market niches for the technology. In the early 90s, my wife and I consulted to some agencies on aspects of this. one such target was emergency medical information .... a person could carry their complete medical records in such a form factor .... and in a life&death emergency .... the emergency crews could pull out the victims card and insert it into their locak, offline, portable display technology and have access to the victims complete medical records. The problem in this scenario was that an emergency first responder isn't likely to be able to make use of the victims medical records in offline manner. First off, if it is a real emergency ... how does a first responder do other than triage. Typically for anything that involves anything more complicated ... the first responder has to go online to "real" doctors at some remote location. If you have a real online environment ... to real (remote) doctors ... then a much better solution is to have something that authenticates the victim ... and the consulting doctor then has some mechanism for locating and retrieving the online medical records (as opposed to first responder being able to make sense out of a victim's complete medical records).

Another niche for the technology was offline financial transactions ... for parts of the world where online connectivity was difficult, non-existent and/or extremely expensive. the smartcard would contain the business rules and logic for performing (offline) financial transaction interacting with random merchant terminals. Two issues arise here .... there is a significant mutual suspicion (lack of trust) problem between random merchant terminals anywhere in the world and random consumer smartcards anywhere in the world; and the technology started to be deployed at a time when online connectivity was starting to become ubiquitous and easily available in most places in the world. An example is the european deployed stored-value (offline) smartcards in the 90s compared to the rapid market penetration of stored-value (online) magstripe (gift, affinity, merchant, etc) cards in the US .... making use of the ubiquitous nature of online connectivity available in the US. Again, which the availability of online .... the problem changes from requiring a very expensive and trusted distributed offline infrastructure and offline distributed business rules .... to the much more simple problem of requiring (increasingly strong) authentication.

So the financial oriented infrastructure has seen some amount of "skimming" threats and exploits with the terminals and/or networks. Even if the smartcard paradigm is just reduced to a (dumb) chipcard that only provides strong authentication .... the issue is does the consumer completely provide their own environment ... or do they have to depend on (and trust) randomly located terminals at random locations around the world.

Part of the authentication issue ... is the 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor the "card" (or chip) provides the something you have piece.

in order to add something you know ... requires the consumer entering a pin or password; the issue then becomes does the consumer trust some randomly located pin-pad. there is a similar issue with whether the consumer trust their own biometric sensor or would they trust somebody else's biometric sensor.

a consumer owned cell phone .... could presumably provide both a consumer trusted pin-pad ... and w/o a whole lot of magic ... a consumer camera cell phone could be used for sensor for various kinds of biometric info.

some part of the issue is that the original target market niche for smartcards (portable computing with fixed interoperable input/output stations) started to evaporate after a lot of the investment had been done but before there was a lot of deployment and investment recovery.

Financial identity is *dangerous*? (was re: Fake companies, real money)

Date: Fri, 29 Oct 2004 07:55:07 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Financial identity is *dangerous*? (was re: Fake companies, real money)
Cc: cryptography@xxxxxxx
At 10:29 AM 10/28/2004, James A. Donald wrote:
Is there a phone that is programmable enough to store secrets on and sign and decrypt stuff?

The ideal crypto device would be programmed by burning new proms, thus enabling easy reprogramming, while making it resistant to trojans and viruses.


there are a couple different trust relationships ... the issue of the user trusting the keyboard/terminal ... and the issue of the relying party trusting the keyboard/terminal.

The FINREAD terminal ... misc. (EU) finread references:
https://www.garlic.com/~lynn/subintegrity.html#finread

supposedly is certified as an stand-alone external keypad and display that can't (very difficult) in being hacked. the financial scenario is that the display can be trusted to display the amount being approved .... the user puts in his card and enters their pin/password. The pin-pad is certified as not being subject to virus keyloggers (that you might find if a PC keyboard was being used).

For the relying party (say an online financial institution) ... the user putting their card into the reader ... and the card generating some unique value ... would indicate to the relying party something you have authentication. The user entering a PIN can both indicate something you know authentication as well as implying that the user aggrees/approves with the value in the display.

Note that the implied agreement/approval ... in not just dependent on the user entering the PIN ... but also on the certification of the terminal ... that the terminal doesn't accept the PIN until after the certified terminal displays the correct value (i.e. there is a certified business process sequence).

The entering of the PIN can also involving transmitting some form of the PIN to the relying party ... and/or the PIN is passed to the smartcard/chip ... and the chip is known to only operate in the appropriate manner when the correct PIN is entered. In this later case, the relying party doesn't actually have knowledge of the something you know authentication .... but the relying party can infer it based on knowing the certified business process operation of all of the components.

Lets say the unique value provided by the smartcard is some form of digital signature ... and the relying party infers from the correct digitial signature something you have authentication. There is still the trust issue between the relying party and the terminal used by the user .... which may also require that the (certified eu finread) terminal also performs a digital signature .... in order for the relying party to be able to trust that it really was a terminal of specific characteristics ... as opposed to some counterfeit or lower-trusted terminal.

There is still the issue of the user trusting such a terminal. If the terminal belongs to the user .... in the user physical home space .... then there isn't as much of a trust issue regarding the user trusting the terminal.

The problem arises for the user if they are faced with using a terminal in some random, unsecured location some place in the world. Even in the situation where a relying party receives a valid transaction with a valid digital signature from a certified, known finread terminal ... there are still a number of MITM attacks on finread terminals that might be located in unsecured locations (various kinds of overlays and/or intermediate boxes capable of performing keylogging and/or modified display presentation).

The personal cellphone and/or PDA ... with user "owned" display and key entry .... is a countermeasure to various kinds of MITM attacks on terminals in public &/or unsecured locations (user has no way of easily proofing that they aren't faced with some form of compromised terminal environment).

Adding reliability and trust to smartcards

Date: Sat, 30 Oct 2004 10:36:49 -0600
To: cryptography@xxxxxxxx
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Adding reliability and trust to smartcards
IST Results - Adding reliability and trust to smartcards
http://istresults.cordis.lu/index.cfm/section/news/tpl/article/BrowsingType/Features/ID/70511

of course ... reliability and trust is more than just the smartcards ... it assurance and trust related to the smartcard infrastructre ... not just the cards themselves.

recent posting on eal5 evaluation, somewhat related
https://www.garlic.com/~lynn/2004m.html#41 EAL5

other parts of the thread
https://www.garlic.com/~lynn/2004m.html#49 EAL5
https://www.garlic.com/~lynn/2004m.html#50 EAL5

semi-related posts about infrastructure
https://www.garlic.com/~lynn/aadsm18.htm#39 Financial identity is *dangerous*? (was re: Fake companies, real money)
https://www.garlic.com/~lynn/aadsm18.htm#40 Financial identity is *dangerous*? (was re: Fake companies, real money)

Payment Application Programmers Interface (API) for IOTP

Refed: **, - **, - **
From: Lynn Wheeler
Date: 11/06/2004 04:05 PM
To: internet-payments@xxxxxxxx
Subject: Payment Application Programmers Interface (API) for IOTP
recently published RFC
https://www.garlic.com/~lynn/rfcidx12.htm#3867

3867 I
Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP), Beykirch H., Hiroya M., Kawatsura Y., 2004/11/05 (106pp) (.txt=234572) (Refs 1738, 2246, 2801, 3538) (was draft-ietf-trade-iotp-v1.0-papi-06.txt)


clicking on the ".txt" field in the summary retrieves the actual RFC. clicking on any of the referenced RFCs goes to the summary for that RFC ... I got a request during Crypto 2004 for more complete indexing in the wake of trying to find all references related to MD5 ... so I finally got around to adding document refs to the summary field. and somewhat aside ... generated a brand new set of summaries just related to MD5
https://www.garlic.com/~lynn/rfcmd5.htm

this is another publication of the IOTP working group of the IETF. Long ago and far away the group started out as trying to map Mondex to Internet environment. Other works that the IOTP working group has done is ECML.

if you click on the actual RFC number in the summary, it brings up all the ways the RFC is indexed; i.e.

3867 - Internet Open Trading Protocol, application program interface

if you click on "Internet Open Trading Protocol", you get the list of all the RFCs from that working group (or at least the list since I started tracking/keeping RFCs by working group) ... aka:

Internet Open Trading Protocol
3867 3506 3505 3504 3354


and the respective summaries:

3506
Requirements and Design for Voucher Trading System (VTS), Eastlake D., Fujimura K., 2003/03/13 (15pp) (.txt=30945) (Refs 2801)

3505 I
Electronic Commerce Modeling Language (ECML): Version 2 Requirements, Eastlake D., 2003/03/13 (8pp) (.txt=13915) (Refs 2246, 2801, 3106)

3504
Internet Open Trading Protocol (IOTP) Version 1, Errata, Eastlake D., 2003/03/13 (6pp) (.txt=8655) (Refs 2801, 2802, 2803)

3354
Internet Open Trading Protocol Version 2 Requirements, Eastlake D., 2002/08/15 (6pp) (.txt=9671) (Refs 2246, 2801, 2802, 3106, 3275)


aka:
https://www.garlic.com/~lynn/rfcidx11.htm#3506
https://www.garlic.com/~lynn/rfcidx11.htm#3505
https://www.garlic.com/~lynn/rfcidx11.htm#3504
https://www.garlic.com/~lynn/rfcidx11.htm#3354

SSL/TLS passive sniffing

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 01 Dec 2004 11:47:37 -0700
To: Dirk-Willem van Gulik <dirkx@xxxxxxxx>
Cc: Ben Nagy <bnagy@xxxxxxxx>, cryptography@xxxxxxxx
Subject: Re: SSL/TLS passive sniffing
At 02:53 AM 12/1/2004, Dirk-Willem van Gulik wrote:
Access to the private key of the server cert gives you the ability to do active sniffing and in some subset of cases passive sniffing. Access to the session key (which requires the right permissions and access to the httpd server) gives you passive sniffing.

It is not uncommon to set this up for customers in the commercial/banking sectors to help them comply with certain audit requirements.

Note however that in each case it requires violating the web servers security realm and/or storing something in two places. So technically it may make much more sense to plug a module into each webserver itself with a sufficiently secure agregation backend to accomplish this.


the other attack is on the certification authorities business process ... crook gets the issuing authority to give them a certificate with all the same information ... but their public key; the key-owner may have little control over the long term business process standards of the issuing certification authority

This is one of the attacks on SSL domain name server certificates. Supposedly the purpose for SSL domain name server certificates was some perceived vulnerabilities in the domain name infrastructure. Note, however, the authoritative agency(s) for domain name ownership is the domain name infrastructure. The current process has a SSL domain name server certificate applicant supplying some amount of identification information. The certification authority then has the error-prone and expensive job of contacting the domain name infrastructure (authoritative agency for domain name ownership) and comparing the supplied identification information (provided with the certificate application) with what is on file at the domain name infrastructure.

The attack isn't on the process that was used for the valid applicant ... the issue is that at any time in the future, can an attacker compromise that process .... using any recognized, valid, certification authority.

The side note is that the certification authority industry has somewhat pushed a business process where the domain name supplies their public key to the domain name infrastructure at the time they register the domain name. Then when somebody applies for a SSL domain name server certificate, they digitally sign the request. The certification authority then just has to retrieve the on-file public key from the domain name infrastructure and validate the digital signature. This turns an expensive and error-prone identification process into a much more reliable and less expensive authentication process.

The catch-22 of course, is that if the certification authorities can retrieve public keys from the domain name infrastructure for authentication ... then just about anybody in the world could do the same thing .... significantly reducing the need for any SSL domain name server certificates.

misc past postings:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
https://www.garlic.com/~lynn/subpubkey.html#certless

SSL/TLS passive sniffing

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 05 Dec 2004 16:07:50 -0700
To: Anton Stiglic <astiglic@xxxxxxxx>
Cc: 'David Wagner' <daw@xxxxxxxx>, bnagy@xxxxxxxx,
cryptography@xxxxxxxx
Subject: Re: SSL/TLS passive sniffing
Anton Stiglic wrote:
I found allot of people mistakenly use the term certificate to mean something like a pkcs12 file containing public key certificate and private key. Maybe if comes from crypto software sales people that oversimplify or don't really understand the technology. I don't know, but it's a rant I have.

i just went off on possibly similar rant in comp.security.ssh where a question was posed about "password or certficate"
https://www.garlic.com/~lynn/2004p.html#60
https://www.garlic.com/~lynn/2004q.html#0

Banks Test ID Device for Online Security

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 05 Jan 2005 23:46:32 -0700
Subject: Re: Banks Test ID Device for Online Security
To: Bill Stewart <bill.stewart@xxxxxxxx>
CC: R.A. Hettinga <rah@xxxxxxxx>,  cryptography@xxxxxxxx
Bill Stewart wrote:
Yup. It's the little keychain frob that gives you a string of numbers, updated every 30 seconds or so, which stays roughly in sync with a server, so you can use them as one-time passwords instead of storing a password that's good for a long term. So if the phisher cons you into handing over your information, they've got to rip you off in nearly-real-time with a MITM game instead of getting a password they can reuse, sell, etc. That's still a serious risk for a bank, since the scammer can use it to log in to the web site and then do a bunch of transactions quickly; it's less vulnerable if the bank insists on a new SecurID hit for every dangerous transaction, but that's too annoying for most customers.

in general, it is something you have authentication as opposed to the common shared-secret something you know authentication.

while a window of vulnerability does exist (supposedly something that prooves you are in possession of something you have), it is orders of magnitude smaller than the shared-secret something you know authentication.

there are two scenarios for shared-secret something you know authentication
  1. a single shared-secret used across all security domains ... a compromise of the shared-secret has a very wide window of vulnerability plus a potentially very large scope of vulnerability
  2. a unique shaerd-secret for each security domain ... which helps limit the scope of a shared-secret compromise. this potentially worked with one or two security domains ... but with the proliferation of the electronic world ... it is possible to have scores of security domains, resulting in scores of unique shared-secrets. scores of unique shared-secrets typically results exceeded human memory capacity with the result that all shared-secrets are recorded someplace; which in turn becomes a new exploit/vulnerability point.
various financial shared-secret exploits are attactive because with modest effort it may be possible to harvest tens of thousands of shared-secrets.

In one-at-a-time, real-time social engineering, may take compareable effort ... but only yields a single piece of authentication material with a very narrow time-window and the fraud ROI might be several orders of magnitude less. It may appear to still be large risk to individuals ... but for a financial institution, it may be relatively small risk to cover the situation ... compared to criminal being able to compromise 50,000 accounts with compareable effort.

In some presentation there was the comment made that the only thing that they really needed to do is make it more attactive for the criminals to attack somebody else.
,br> It would be preferabale to have a something you have authentication resulting in a unique value ... every time the device was used. Then no amount of social engineering could result in getting the victim to give up information that results in compromise. However, even with relatively narrow window of vulnerability ... it still could reduce risk/fraud to financial institutions by several orders of magnitude (compared to existing prevalent shared-secret something you know authentication paradigms).

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

Banks Test ID Device for Online Security

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 06 Jan 2005 06:52:30 -0700
Subject: Re: Banks Test ID Device for Online Security
To: Bill Stewart <bill.stewart@xxxxxxxx>
CC: R.A. Hettinga <rah@xxxxxxxx>, cryptography@xxxxxxxx
oh, and this is old discussion of a unit that has been in use in europe ... it basically is very inexpensive calculator with 7816 contacts that you can slip a smartcard into. it is used in a challenge/response scenario, a numeric keypad is used to enter the challenge, which is passed to the smartcard, which does something and the response is displayed. the person enters the displayed response.
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking

works with anything that can present a challenge and has a numeric keypad for the response (even works over telephone with VRU).

note that in any online scenario ... the server-side can do security proportional to risk by making a decision to ask or not ask for additional inputs. possible scenario is bill pay in home banking, use authentication for initial access and then if total transactions exceed some value ... ask for additional authentication input (trading off convenience and risk, in online scenario it doesn't need to be all just one way or another way, there is some amount of latitude for adaptive implementation).

Note that the additional authentication input can also be used for interpreting the (human specific) input as evidence of approval for the transaction(s) as opposed to simply authentication.

other pieces of the previous mentioned thread on security proportional to risk:
https://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
https://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#62 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#64 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#68 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#70 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#75 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#10 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#35 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???

Dell to Add Security Chip to PCs

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dell to Add Security Chip to PCs
Date: Fri, 04 Feb 2005 11:07:32 -0700
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: camera_lumina@xxxxxxxx,
cryptography@xxxxxxxx,
rah@xxxxxxxx
Peter Gutmann wrote:
Neither. Currently they've typically been smart-card cores glued to the MB and accessed via I2C/SMB.

and chips that typically have had eal4+ or eal5+ evaluations. hot topic in 2000, 2001 ... at the intel developer's forums and rsa conferences

Dell to Add Security Chip to PCs

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dell to Add Security Chip to PCs
Date: Fri, 04 Feb 2005 11:12:59 -0700
To: Erwann ABALEA <erwann@xxxxxxxx>
CC: Trei, Peter <ptrei@xxxxxxxx>,
Tyler Durden <camera_lumina@xxxxxxxx>,
    rah@xxxxxxxx, cryptography@xxxxxxxx
Erwann ABALEA wrote:
I've read your objections. Maybe I wasn't clear. What's wrong in installing a cryptographic device by default on PC motherboards? I work for a PKI 'vendor', and for me, software private keys is a nonsense. How will you convice "Mr Smith" (or Mme Michu) to buy an expensive CC EAL4+ evaluated token, install the drivers, and solve the inevitable conflicts that will occur, simply to store his private key? You first have to be good to convice him to justify the extra depense. If a standard secure hardware cryptographic device is installed by default on PCs, it's OK! You could obviously say that Mr Smith won't be able to move his certificates from machine A to machine B, but more than 98% of the time, Mr Smith doesn't need to do that. Installing a TCPA chip is not a bad idea. It is as 'trustable' as any other cryptographic device, internal or external. What is bad is accepting to buy a software that you won't be able to use if you decide to claim your ownership... Palladium is bad, TCPA is not bad. Don't confuse the two.

the cost of EAL evaluation typically has already been amortized across large number of chips in the smartcard market. the manufacturing costs of such a chip is pretty proportional to the chip size ... and the thing that drives chip size tends to be the amount of eeprom memory.

in tcpa track at intel developer's forum a couple years ago ... i gave a talk and claimed that i had designed and significantly cost reduced such a chip by throwing out all features that weren't absolutely necessary for security. I also mentioned that two years after i had finished such a design ... that tcpa was starting to converge to something similar. the head of tcpa in the audience quiped that i didn't have a committee of 200 helping me with the design.

one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: cryptography@xxxxxxxx
Subject: one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
Date: Tue, 08 Feb 2005 07:38:10 -0700
Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/02-08-2005/0002986646&EDATE=
According to a recent study jointly released by Vontu Inc., the leader in Data Loss Prevention solutions, and the Ponemon Institute, a research institute dedicated to privacy management practices in business and government, the most likely threat to information security is not the typical hacker, virus or worm, but rather the malicious or careless corporate insider.

... snip ...

link-layer encryptors for Ethernet?

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: link-layer encryptors for Ethernet?
Date: Wed, 09 Feb 2005 09:27:26 -0700
To: Joseph Tardo <tardo@xxxxxxx>
CC: Steven M. Bellovin <smb@xxxxxx>,  cryptography@xxxxxxx
Joseph Tardo wrote:
DEC used to make one (the DESNC), I don't remember the Xerox product. Cylink used to make one, and may even still (as Safe-Net). FWIW, IEEE has working group 802.1ae doing Ethernet MAC layer encryption. But then, they had 802.10 (only implementation I know of was the DESNC) for many years before retiring it. The market for these kinds of devices has been notoriously small. May I ask what your use case is?

the internal network was larger than the arpanet/internet just about the whole time up until about mid-85. all the links leaving physical premises had to be encrypted ... there was the claim that over half of all link encryptors in the world were on the internal network (and put at least one of the major products/companies into business). lots of random comments about the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

small sample posting about the internal net passing 1000 nodes not long after internet passed 255 nodes.
https://www.garlic.com/~lynn/internet.htm#22

one of the big issues in part of this period was getting link encryptors on links that cross national boundaries.

link-layer encryptors for Ethernet?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: link-layer encryptors for Ethernet?
Date: Wed, 09 Feb 2005 10:26:57 -0700
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Joseph Tardo <tardo@xxxxxxxx>,  cryptography@xxxxxxxx
Steven M. Bellovin wrote:
Yup. Often, large corporations had policies requiring them, because of how frequently a transoceanic fiber would be cut and the circuits rerouted to satellite.

how 'bout microwave terrestrial ... remember all the press about the consulate in san fran that supposedly had clear shot at the mci microwave antenna complex?

san jose south valley complex had T3 collins digital radio between the main plant site (roof of bldg. 12) and stl/bldg.90. i've heard comments from people driving the stretch of 87 having their radar detectors go off when they are in the straight line between bldg. 12 and the repeating tower on top of the hill going to bldg.90.

a similar setup went to the lsg/bldg.29 (los gatos lab) ... with a repeating tower on the hill above san jose dump.

my hsdt project had some of the circuits
https://www.garlic.com/~lynn/subnetwork.html#hsdt

and also put in a tdma system that ran off a transponder on sbs4. had 4.5meter dish in the back parking lot of bldg.29 with tail circuits to the main plant site, a 4.5meter dish out behind yorktown research, and a 7meter dish on the austin plant site.

i got tired of paying all the money for the link encryptors ... and got involved in designing a board that was a lot more powerful and orders of magnitude cheaper ... which caused some churn.

A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Amir Herzberg <herzbea@xxxxxxxx>,
Ian Grigg <iang@xxxxxxxx>,  cryptography@xxxxxxxx
Date: Thu, 10 Feb 2005 19:03:37 -0700
Steven M. Bellovin wrote:
"Unusual CA"? I'm not sure what a *usual* CA is.

Just for fun, I opened up the CA list that came with my copy of Firefox. There are no fewer than 40 different entities listed, many of whom have more than one certificate. I personally know less than half of them to be trustworthy -- and that's assuming that, say, Thawte, Thawte Consulting, and Thawte Consulting cc are all the same company and I can count that as three different ones. I had no idea that the U.S. Postal Service had a CA that was trusted by my browser -- and I dare say that many non-Americans wouldn't trust it at all, on the assumption that it would do whatever the U.S. government told it to do.


cylink had the contract ... bea had subcontract. usps was going to do some sort of in-person verification before issuing the certificate ... along the lines of US passports.
https://web.archive.org/web/20050212211937/http://www.gcn.com/17_24/news/33918-1.html

this dates back to the days when the CA industry was floating business cases that there was going to be $100/annum x.509 identity certificate for every person in the country (the $20b/annum gift to the CA industry story).

there was some rumor that if the gov. wouldn't cough up the $20b/annum, then the financial industry was just chopping at the bit to turn over $20b/annum to certification authorities. there is a story from the period about an offer to a financial institution that if they would transmit a copy of the master account database of tens of millions of customers to the certification authority ... the certification authority would re-arrange the bits in each database entry into this magic format called a certificate and return the re-arranged magic bits to the financial institution at a mere $100/database entry (nominally overnight ... but possibly actually several days, maybe only earning the CA a measely $1b/day of work).

this overlapped with the realization that identity certificates were composed at some point in the past w/o any knowledge of just what identity information any future relying parties might require .... as a result there was one strategy that it would be necessary to overload all identity certificate with every possibly piece of identity information so as to cover all possible requirements possibly needed by future unknown relying parties.

at the same time, the financial industry was realizing that identity certificates represented huge privacy and liability exposures ... and so you started to see retrenching by various parties (particularly the financial industry) to relying-party-only certificates. misc. past posts about relying-party-only certificates:
https://www.garlic.com/~lynn/subpubkey.html#rpo

The problem lurking in the background is that fundamentally, the certificate design-point is an offline paradigm in a situation where the relying-party has absolutely no recourse for obtaining information about the origin of the digital signature (so is reduced to operating with a letter-of-credit paradigm from the sailing ship era).

This fact was well highlighted in digitally signed payment scenario. A bank customer was issued a relying-party-only certificate by their financial institution (after registering their public key in the financial institution's account record). The customer would then create a payment authorization message, digitally sign the message and then transmit the message, the digital signature and the bank's relying-party-only certificate back to the bank. Since the bank already has the customer's public key on file, the first thing it does is discard the transmitted certificate and verifies the digital signature with the on-file public key.

Another minor annoyance was that typical digital certificate was nominally two orders of magnitude (one hundred times) larger than the typical 8583 payment message. So not only were the relying-party-only certificates redundant and superfluous ... its only apparent purpose was to increase transmission payload bloat by a factor of 100 times.

some past posts about browser trusted public key lists:
https://www.garlic.com/~lynn/aepay4.htm#comcert14 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates
https://www.garlic.com/~lynn/2003l.html#27 RSA vs AES

ATM machine security

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: ATM machine security
Date: Tue, 22 Feb 2005 10:00:35 -0700
To: Lee Parkes <leep@xxxxxxxx>
CC: cryptography@xxxxxxxx
Lee Parkes wrote:
Hi,
I'm working on a project that requires a benchmark against which to judge various suppliers. The closest that has similar requirements is the ATM industry. To this end I'm looking for any papers, specifications or published attacks against ATM machines and their infrastructure. I'm also looking for what type of networks they use and the crypto they use to protect comms. Also any standards would be good that the ATM industry has to adhere to.


messages/networks tend to be some flavor of iso8583 (used for both credit and debit). most associations have requirement for DUKPT (derived unique key per transaction) DES and transition to 3DES.

do search engine some flavor of 8583, dukpt, and/or x9 (x9 is the us/ansi financial standards organization ... they have some recognition at places like NIST where they've gotten around to saying that they no longer have to rewrite X9 crypto standards for FIPS ... but can directly reference the X9 documents).

lots of the attacks aren't directly on the ATM machines ... but on the cards used at ATM machines ... aka skimming attacks. there is the stuff about overlays on the front of ATM machines to capture information as the card passes thru for valid transations. the captured information is then used to manufactur counterfeit cards (i think there was even a scene on this on one of last seasons CSI tv shows).

MD5 collision in X509 certificates

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: MD5 collision in X509 certificates
Date: Sat, 05 Mar 2005 09:23:11 -0700
To: Victor Duchovni <Victor.Duchovni@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Victor Duchovni wrote:
What is the significance of this? It seems I can get a certificate for two public keys (chosen, not given) while only proving posession of the first. Is there anything else? In what sense is the second public key useful to the attacker?

the purpose of a certificate is analogous to the old letters of credit in the sailing ship days .... it supposedly establishes the bonifides of the individual in an offline, non-connected world where the relying party has no other recourse regarding trust/integrity of the individual that they are dealing with.

in the PKI/certificate world ... the relying party receives some sort of digitally encrypted/signed information and validates it using the public key presented in the attached certificate. a correctly validation then implies some kind of 3-factor authentication (although the PKI/certificate paradigm tends to totally gloss over this characteristic, instead attempting to focus the communities attention on the value of the certification as opposed to focusing the attention on any possibility/value/trust that some part of 3-factor authentication might have occured).

In any case, if the public key (from some source, possibly a certificate) is able to validate the transmission, then the relying party assumes that some portion of 3-factor authentication occured in the access and use of the corresponding private key ... possibly
https://www.garlic.com/~lynn/subintegrity.html#3factor in any case, given that the relying party accepts the validation by the public key as representing some implied 3-factor authentication involved in access and use of the corresponding private key ... then the relying party may be faced with just who the implied authentication corresponds to. In the typical, long time accepted business process ... the relying party will have prior relationship with the entity being authenticated and it will be explicit and/or implicit in the communication itself. In the more modern world, in the situations where the relying party has no prior relationship with the authenticated entity ... they will have access to online and/or real-time information to establish that fact.

However, certificates were targeted at the offline email world ... where the email was created, digitally signed (presumably after some form of 3-factor authentication occuring to establish access/use of the private key), and the email, digital signature, and certificate packaged up and sent off to some party that there had been no previous communciation (might be considered spam in this day and age). After some number of intermediary store-and-forwards stops, the package arrives at the post office of the relying party. the relying party eventually calls their post office, exchanges emails and hangs up.

At this point the relying party is presented with a digital signed message with whom that they had no prior communciation. The attached certificate provides the public key for validating the digital signature and the rest of the certificate contents is supposedly to attest to some characteristic of the email sending party (that the relying party has no other way of validating).

The implication is that if i can substitute a public key in some certificate that attests to represent some other party .... then it may be some form of identity theft (fraudulent messages can be created that otherwise appear to have originated from you ... and validate with the substituted public key). The other might be elevation of privileges .... adding characteristics to a certificate that were otherwise not provided.

MD5 collision in X509 certificates

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: MD5 collision in X509 certificates
Date: Sat, 05 Mar 2005 11:13:40 -0700
To: Victor Duchovni <Victor.Duchovni@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Victor Duchovni wrote:
What is the significance of this? It seems I can get a certificate for two public keys (chosen, not given) while only proving posession of the first. Is there anything else? In what sense is the second public key useful to the attacker?

so three kinds of attacks on certificate contents ... the previously two mentioned the other is possibly by the relying party against the key owner.

in the early '90s identity certificates were all the rage. some problems were at the time the certification took place ... it might not be possible for the certification authority to determine all possible kinds of identity information that a relying party (at any point in the future) might require ... so there was a trend to overloading an identity certificate with all possible types of identity information on the off chance that something might be useful to some relying party in the future. this led to increasing realization that such collection of identity information might represent various kinds of privacy violation and you saw some retrenching to relying-party-only certificates in the mid-90s ... misc. relying-party-only certificates only containing an account number to be used in online/real-time transaction (note however, in online/real-time relying-party-only scenario it is also trivial to show that certificates are redundant and superfluous)
https://www.garlic.com/~lynn/subpubkey.html#rpo

the other thing in the 90s was trying to project a value proposition for certificates. there was a lot of FUD and confusion generated about the value of certificates to the point that it was frequently obscured that it was even necessary to have security and safety around the protection and use of the private key ... and/or that any form of 3-factor authentication was even involved in the access and use of the private key. To this day, you have people writing about using a digital certificate to create a digital signature.

So another value representation for digital certificates was that of non-repudiation. basically if the non-repudiation flag in a digital certificate was checked/marked ... then the relying party could assume non-repudiation on the part of the originating party. Again this is a scenario trying to represent the value of a digital certificate in place of the safety and security around the access and use of the private key.

So the story given to merchants in the merchant/consumer market place .... was that the existing circumstances were that in any dispute the burden of proof is on the merchant .... but the proposal was that if a merchant could produce any certificate (for the consumer/originator public key) that had the non-repudiation flag marked/checked, then the burden of proof (in a dispute) would shift from the merchant to the consumer.

So if that effort had been successful ... then it would be in the interest of merchants to be able to produce a consumer digital certificate that included the non-repudiation flag (regardless of whether that certificate had been used in the original transaction or not .... since by definition all burden of proof then is shifted to the consumer).

some of this is discussed in various postings regarding finread ... where the EU attempted to dictate some minimum hardware environment that would provide some level of assurance around the access and use of the private key (which helps diffuse the confusion around whether the digital signature value proposition relies solely in the existance of a digital certificate .... or whether there is some value in controlling the access and use of private keys .... and it possibly isn't the case that digital signatures are generated by digital certificates):
https://www.garlic.com/~lynn/subintegrity.html#finread

other past postings on 3-factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor

two-factor authentication problems

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: two-factor authentication problems
Date: Mon, 07 Mar 2005 15:36:23 -0700
To: gabriel@castelain.com.au
CC: 'Matt Crawford' <crawdad@fnal.gov>, 'Ed Gerck' <egerck@nma.com>,
    cryptography@metzdowd.com
Gabriel Haythornthwaite wrote:
You're quite correct Matt,

Which is why IMHO you can only really get true non-repudiation through use of PKI. And more specifically: - where the key pair was generated by the end-user, and - where the server has stored a copy of the transaction - digitally signed by the end user - which it can reproduce in court.

In this case, a corrupt operator could not have faked the transaction even if they had wanted to.

RSA SecureID and OATH technology have some great virtues:
- they cost nothing to integrate at the client end - there is no client "footprint" so there's nothing to go wrong
- they are relatively easy to understand and use
- they're unquestionably better than reliance on user IDs and passwords.

What they won't do is:
- provide non-repudiation
- defend against man-in-the-middle attacks, or
- provide a robust defence against phishing scams

And for these reasons I suspect their days are numbered.


in general, non-repudiation is a legal term and is associated with a legal signature ... which implies a person has read, understood, agrees, approves, and/or authorizes what is being signed.

a digital signature is somewhat of a semantic misnomer since by itself, it carries none of the characteristics commonly associated with a legal signature.

a digital signature, by itself, implies that some entity has accessed and used a specific private key. there is nothing in the standard, basic PKI infrastructure that either
  1. implies that anything associated with any form of 3-factor authentication was necessary in the access and use of a private key (in the generation of a digital signature)
  2. that there was any demonstration that there was any reading, understanding, agreement, approval, and/or authorization associated with the access and/or use of a private key (in the generation of a digital signature).
part of this i pointed out in a number of postings on dual-use digital signature attack ... where the scenario is that digital signature is being used to imply simple authentication aka possibly some flavor of a challenge was transmitted, the receiving entity then used a private key to digitally sign the challenge and return the digital signature (there is a extremely vague implicit assumption that any component of 3factor authentication was used in access and use of the private key ... with the existance of a digital signature hopefully implying that some component of 3factor authentication actually occured in the access and use of the private key).

issues are
  1. frequently challenge type protocols don't bother to present (the possibly totally random) bits (being signed) to the entity (that is assumed to be associated with the digital signature).
  2. frequently infrastructures that attempt to equate legal signature and digital signature ... will accept the existance of a digital signature applied to some number of bits as representing that the associated entity actually read, understood, agrees, approves, and/or authorizes the semantic meaning associated with the bits that were signed ... w/o requiring either a) some demonstration/proof that 3factor authentication was used in the access and use of the private key for the digital signature and/or b) that the meaning of what was digital signed had actually been read, understood, agrees, approves, and/or authorizes
in the dual-use attack, bits that might have semantic meaning are presented as random and/or meaningless as part of an authentication challenge/response protoocol. The attacker then takes and represents that the challenge bits that were signed ... were actually signed in the sense of a legal signature.

as a totally extraneous observation ... the discussion up to this point has been totally agnostic with regard to whether an infrastructure attempting to show some relationship between a digital signature and a legal signature involves PKI in anyway what so ever and/or is totally certificate-less with regard to establishing a relationship between an entity and what might be assumed from the existance of a digital signature.

past posts regarding 3-factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor

EU finread standard attempting to address some of the issues regarding providing some level of assurance about 1) any characteristic of 3factor authentication actually occuring when the private key was accessed and used for a digital signature and 2) the entity might have actually read and approves the transaction
https://www.garlic.com/~lynn/subintegrity.html#finread

past posts on dual-use vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
https://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#35 Credit card leaks continue at a furious pace
https://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004m.html#4 REVIEW: "Biometrics for Network Security", Paul Reid
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns

past posts on non-repudiation ... and possibly some characteristics that might be required to demonstrate a person has read, understood, agrees, approves, and/or authorizes what was digitally signed:
https://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on
https://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aepay11.htm#22 FBI Probing Theft of 8 Million Credit Card Numbers
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
https://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#ocrp Online Certificate Revocation Protocol
https://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
https://www.garlic.com/~lynn/aadsm6.htm#nonreput Sender and receiver non-repudiation
https://www.garlic.com/~lynn/aadsm6.htm#nonreput2 Sender and receiver non-repudiation
https://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror10 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
https://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
https://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki9 Software for PKI
https://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
https://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm10.htm#cfppki13 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
https://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
https://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
https://www.garlic.com/~lynn/aadsm10.htm#bio7 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
https://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign
https://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses "Authority-stamp-signatures"
https://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
https://www.garlic.com/~lynn/aadsm14.htm#20 Payments as an answer to spam (addenda)
https://www.garlic.com/~lynn/aadsm14.htm#23 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
https://www.garlic.com/~lynn/aadsm14.htm#48 basic question: semantics of "map", "tie", etc in PKI
https://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
https://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#37 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#40 FAQ: e-Signatures and Payments
https://www.garlic.com/~lynn/aadsm16.htm#9 example: secure computing kernel needed
https://www.garlic.com/~lynn/aadsm16.htm#11 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
https://www.garlic.com/~lynn/aadsm16.htm#14 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm16.htm#17 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm16.htm#18 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm16.htm#23 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#28 Definitions of "Security"?
https://www.garlic.com/~lynn/aadsm17.htm#53 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#55 MD5 collision in X509 certificates
https://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week
https://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
https://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
https://www.garlic.com/~lynn/2001g.html#1 distributed authentication
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
https://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
https://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
https://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
https://www.garlic.com/~lynn/2002d.html#16 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002d.html#41 Why?
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#29 Crazy idea: has it been done?
https://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
https://www.garlic.com/~lynn/2002e.html#58 O'Reilly C Book
https://www.garlic.com/~lynn/2002f.html#10 Least folklorish period in computing (was Re: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002f.html#23 Computers in Science Fiction
https://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
https://www.garlic.com/~lynn/2002f.html#45 Biometric Encryption: the solution for network intruders?
https://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
https://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002j.html#24 Definition of Non-Repudiation ?
https://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
https://www.garlic.com/~lynn/2002k.html#42 MVS 3.8J and NJE via CTC
https://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
https://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
https://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#36 (OT) acceptance of technology, was: Convenient and secure
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
https://www.garlic.com/~lynn/2002p.html#23 Cost of computing in 1958?
https://www.garlic.com/~lynn/2003e.html#47 Public key and the authority problem
https://www.garlic.com/~lynn/2003f.html#35 Public Encryption Key
https://www.garlic.com/~lynn/2003f.html#37 unix
https://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003h.html#18 Authentication protocol
https://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature
https://www.garlic.com/~lynn/2003h.html#38 entity authentication with non-repudiation
https://www.garlic.com/~lynn/2003h.html#42 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs
https://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
https://www.garlic.com/~lynn/2003.html#29 Message (authentication/integrity); was: Re: CRC-32 collision
https://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
https://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
https://www.garlic.com/~lynn/2003k.html#6 Security models
https://www.garlic.com/~lynn/2003l.html#65 Strength of RSA with known plain-text
https://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the same key for authentication and encryption
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003o.html#22 securID weakness
https://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
https://www.garlic.com/~lynn/2003o.html#44 Biometrics
https://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
https://www.garlic.com/~lynn/2003p.html#11 Order of Encryption and Authentication
https://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
https://www.garlic.com/~lynn/2004e.html#20 Soft signatures
https://www.garlic.com/~lynn/2004h.html#13 Two-factor Authentication Options?
https://www.garlic.com/~lynn/2004h.html#30 ECC Encryption
https://www.garlic.com/~lynn/2004.html#29 passwords
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004m.html#4 REVIEW: "Biometrics for Network Security", Paul Reid
https://www.garlic.com/~lynn/2005d.html#32 Is a cryptographic monoculture hurting us all?


AADS Postings and Posting Index,
next, previous - home