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:
http://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:
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm15.htm#40 FAQ: e-Signatures and Payments
http://www.garlic.com/~lynn/aadsm16.htm#9 example: secure computing kernel needed
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
http://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
http://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
http://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)
http://www.garlic.com/~lynn/aadsm17.htm#53 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming
http://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)
- 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)
- there are a certain class of certified hardware tokens which
contain unique private keys.
- 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
- 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.
- relying party gets a signed message
- the relying party can verify the digital signature with a specific
public key known to be associated with a known hardware token
- the known hardware token is known to be in the possession of a
specific person .... which implies something you have authentication
- the known hardware token is known to satisfy requirements #2 and #4
- the corresponding terminals that the hardware token works with are
known to satisfy requirements #1 and #4
- 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
- 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).
- 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 writting 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 theoritically 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
- integrity of the transaction message,
- authenticated the origin, and
- 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
http://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.
http://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).
http://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.
http://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
http://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
http://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 useage 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
guarentee 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:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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
http://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
http://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 succesfully 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:
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
http://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
http://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
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
http://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:
http://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
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 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 ....
http://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
- the public key doesn't have to be kept confidential as part of the
distribution
- you don't need a unique key for every unique security &/or business
domain
- 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 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:
- 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.
- 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:
http://www.garlic.com/~lynn/aadsm17.htm#12 A combined EMV and ID card
http://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
http://www.tc68.org
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
http://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:
http://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
http://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
http://www.garlic.com/~lynn/subpubkey.html#privacy
misc. past postings mentioning privacy/identity agnostic:
http://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aepay7.htm#liberty Network Identity Alliance -- Liberty Alliance Project
http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias
http://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
http://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:
http://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:
http://www.garlic.com/~lynn/subintegrity.html#3factor
- something you know
- something you have
- something you are
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:
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
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):
http://www.garlic.com/~lynn/2004h.html#48 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#50 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#52 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#53 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#54 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#55 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#56 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#57 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#59 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#2 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#4 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#9 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#10 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#11 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#12 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#13 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#14 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#15 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#19 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#20 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#22 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#23 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#25 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#27 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#0 New Method for Authenticated Public Key Exchange without Digital Certificates
htt