Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next, previous
- home
- dual-use digital signature vulnerability
- dual-use digital signature vulnerability
- dual-use digital signature vulnerability
- dual-use digital signature vulnerability
- dual-use digital signature vulnerability
- Using crypto against Phishing, Spoofing and Spamming
- dual-use digital signature vulnerability
- Using crypto against Phishing, Spoofing and Spamming
- E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
- E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
- E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
- E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
- dual-use digital signature vulnerability
- dual-use digital signature vulnerability
- In Search of Eve - the upper boundary on Mallory
- In Search of Eve - the upper boundary on Mallory
- In Search of Eve - the upper boundary on Mallory
- should you trust CAs? (Re: dual-use digital signature vulnerability)
- Any TLS server key compromises?
- RPOW - Reusable Proofs of Work
- RPOW - Reusable Proofs of Work
- RFC 3833 Threat analysis of the domain name system (DNS)
- [anonsec] Re: potential new IETF WG on anonymous IPSec
- public-key: the wrong model for email?
- public-key: the wrong model for email?
- public-key: the wrong model for email?
- public-key: the wrong model for email?
- EMV cards as identity cards
- x9.99 privacy note
- EMV cards as identity cards
- Academics locked out by tight visa controls
- EMV cards as identity cards
- EMV cards as identity cards
- An interesting "new" computer security problem
- An interesting "new" computer security problem
- Credit card leaks continue at a furious pace
- Phishing losses total $500 million - Nacha
- Fake Companies, real money; elaborate con wrings cash out of stolen credit cards
- How to store the car-valued bearer bond? (was Financial identity...)
- Financial identity is *dangerous*? (was re: Fake companies, real money)
- Financial identity is *dangerous*? (was re: Fake companies, real money)
- Adding reliability and trust to smartcards
- Payment Application Programmers Interface (API) for IOTP
- SSL/TLS passive sniffing
- SSL/TLS passive sniffing
- Banks Test ID Device for Online Security
- Banks Test ID Device for Online Security
- Dell to Add Security Chip to PCs
- Dell to Add Security Chip to PCs
- one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
- link-layer encryptors for Ethernet?
- link-layer encryptors for Ethernet?
- A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
- ATM machine security
- MD5 collision in X509 certificates
- MD5 collision in X509 certificates
- two-factor authentication problems
dual-use digital signature vulnerability
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 Jul 2004 10:32:44 -0600
To: Amir Herzberg <herzbea@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxxx>, cryptography@xxxxxxxx
start of post:
https://www.garlic.com/~lynn/aadsm17.htm#59
the fundamental issue is that there are infrastructures using the same
public/private key pair to digital sign
1) random authentication data that signer never looks at and believe
is of low value ... i.e. if they connect to anybody at all ... and are
asked to digitally sign some random data for authentication purposes
... they do it.
2) contents that they supposedly have read, understood,
agrees, approves, and/or authorizes.
i haven't seen any definition of data arriving at the relying party
where the relying party has proof of whether it was case #1 or case
#2. The closest was the non-repudiation bit in a certificate. however,
the non-repudiation bit in a certificate was put in there at the time
the certificate was manufactured and in no way applies to the
environment and conditions under which the signature in question
actually occurred.
there are definitions like non-repudiation services and/or the EU
FINREAD definition ... which purports to specify the environment under
which the (real) "signatures" take place. Note however, while the EU
FINREAD defines an environment where there is some indication that the
signing party might have read and agreed to the contents of what is
being signed .... there is nothing in the EU FINREAD specification
that would provide proof to the relying party that a FINREAD terminal
was actually used for any specific signing. Anything, like a flag
... not part of a signed message ... that might be appended to the
transmission ... that makes claims about whether a FINREAD terminal
was used or not ... could have originated from anywhere .... analogous
to the example where a relying party might be able to substitute a
certificate with the non-repudiation bit set .... in order to change
the burden of proof from the relying party to the signing party ... in a
legal dispute ... more the mid-90s ... where non-repudiation flag in a
certificate might have been thought to have some valid meaning (since
the certificate wasn't covered by the signature .... anybody could
claim any valid certificate was the certificate used for the
transaction)
In any case, if a signing party has ever used their private key to
sign random data that they haven't read ..... and they are ever
expected to use the same private key in legal signing operations where
they are presumed to have read, understood, agrees, approves, and/or
authorizes the contents .... and there is no proof provided (or
included) as part of the signed message that the signing occurred in a
specified (non-repudiation) environment ... then there is no way that
a relying party can prove or disprove under what conditions a digital
signing actually occurred.
misc. past post reference EU FINREAD:
https://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
https://www.garlic.com/~lynn/aadsm15.htm#40 FAQ: e-Signatures and Payments
https://www.garlic.com/~lynn/aadsm16.htm#9 example: secure computing kernel needed
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
https://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
https://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
https://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature
dual-use digital signature vulnerability
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 Jul 2004 11:25:17 -0600
To: Sean Smith <sws@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
Amir Herzberg <herzbea@xxxxxxxx>, cryptography@xxxxxxxx
At 10:36 AM 7/18/2004, Sean Smith wrote:
In SSL and TLS, the client isn't signing random data provided by the
adversary. Rather, the client is signing a value derived from data
both the client and server provide as part of the handshake. I do not
believe it is feasible for a malicious server to choose its nonces so
that the resulting signature be coincide with a valid signature on a
delegation cert the client might have constructed.
the issue in the EU FINREAD scenario was that they needed a way to
distinguish between (random) data that got signed ... that the key
owner never read .... and the case were the key owner was actually
signing to indicate agreement, approval, and/or authorization. They
specified a FINREAD terminal which supposedly met the requirements that
the key owner had to have read and to some extent understood .... and
approved as to the meaning of the contents of what was being signed.
However, the FINREAD specification didn't define any mechanism that
provided proof to the relying party that a FINREAD terminal was
actually used as part of the signature process.
Some of the non-repudiation service definitions also talk about
processes that would provide high likelyhood that the person
performing the signing has read, understood, agrees, approves,
and/or authorizes the contents of what is being signed. However,
many of them fail to specify a mechanism that proves to a relying
party that such a non-repudiation service was actually used.
so the dual-use attack .... is if a key-owner ever, at any time, signs
something w/o reading it ... then there is the possibility that the
data being signed actually contains something of significance.
if there is never any proof, included as part of the integrity of the
message ... that proves to the relying party that some sort of
non-repudiation environment was used as part of the digital signing
.... then it falls back on requiring an exhaustive proof that never in
the history of the private key was it ever used to sign contents that
were unread and could possibly be used in a dual-use attack.
it isn't sufficient that you show there is some specific
authentication protocol with unread, random data ... that has
countermeasures against a dual-use attack ... but you have to
exhaustively show that the private key has never, ever signed any
unread random data that failed to contain dual-use attack
countermeasure
the alternative to the exhaustive proof about every use of the private
key .... is strong proof (that is built into the integrity of the
signed contents) that non-repudiation environment was used for the
digital signing (strong implication that the key owner, read,
understood, agrees, approves, and/or authorizes the contents of the
message).
the NIST alternative scenario for a exhaustive proof ... rather than
exhaustive proof about every use of a specific private key .... would
be able to show that it is impossible to use the private keys in any
protocol not written by the people making the presentation
this came up in a SET discussion long ago and far away. it was about
whether there was ever any SET gateway implementation that could set the
signature verified bit in the ISO 8583 message. One of the SET
vendors claimed that the software they shipped was certified that it
would never set the signature verified bit in the ISO 8583 message,
if the signature hadn't actually been verified (and therefor there
wasn't an infrastructure vulnerability). The problem was that they had
created an infrastructure that didn't require end-to-end proof of the
signature verification ... and they were unable to control that every
ISO 8583 generated message .... was certified as only being able to be
generated by their code. They had created an infrastructure
vulnerability .... that allowed a wide variety of software to be used
.... and was only safe if they could prove that every copy of code
generating every ISO 8583 messages was their code and it was
impossible to modify and/or substitute something else in the
generation of an ISO 8583 message.
The countermeasure to the seriously flawed SET design requiring
exhaustive proof that every ISO 8583 message that was ever created
that carried the signature verified bit .... could have only
been created by unmodified, certified software .... was to support
end-to-end authentication. ... And for a slight drift ... that wasn't
practical in the SET design because the inclusion of a certificate
would have represented horrendous payload bloat of two orders
of magnitude (discussed in some detail in recent previous posts to
this mailing list)
https://www.garlic.com/~lynn/aadsm17.htm#53 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
dual-use digital signature vulnerability
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
Refed: ** -, ** -, ** -, **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 Jul 2004 13:28:17 -0600
To: Amir Herzberg <herzbea@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: cryptography@xxxxxxxx
there is a variation on the EU FINREAD terminal that sort of provides
a chain of trust/evidence (that has almost nothing at all to do with
the traditional trusted third party certification authorities and
their certificates)
- 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 writing some number of apps to be able to use
the EMV cards for other applications.
this is from yesterday
http://www.smartcardalliance.org/industry_news/industry_news_item.cfm?itemID=1316
which talks about additional applications (in addition to expected RSA
signing at EMV point-of-sale terminals)
• OneSMART MasterCard Authentication - ensures a higher level of security for online shopping and remote banking
• OneSMART MasterCard Web - allows cardholders to securely store and manage a wide range of personal data (such as names, addresses, URLs, log-on passwords) on the smart card chip
• OneSMART MasterCard Pre-Authorised - a new chip-based payment solution suitable for new markets and off-line payment environments
===
it doesn't give any details but possibly if the expected RSA signing
at EMV point-of-sale terminals is an example of aggreement/approval
... then the authentication application may be RSA signing of some
sort of challenge data .... and i would guess that few, if any people
make it a habit to examine presented challenge data.
part of the issue is creating an environment where all authentication
protocols and all authentication implements are required to have
countermeasures against dual-use attack on signing of documents or
transactions ... means that loads of stuff have to be perfect in the
future.
the other is requiring more proof regarding the signing environment to
be carried when the signing is associated with approval, agreement,
and/or authorization (more than simple authentication) .... for
instance that for some of the non-repudiation features (that
supposedly address such issues) .... that they have to also sign in
some manner to indicate non-repudiation features being in
place.
dual-use digital signature vulnerability
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 19 Jul 2004 09:26:18 -0600
To: Jerrold Leichter <jerrold.leichter@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: Sean Smith <sws@xxxxxxxx>,
Amir Herzberg <herzbea@xxxxxxxx>, cryptography@xxxxxxxx
At 08:25 AM 7/19/2004, Jerrold Leichter wrote:
A traditional "notary public", in modern terms, would be a tamper-resistant
device which would take as inputs (a) a piece of text; (b) a means for
signing (e.g., a hardware token). It would first present the actual text
that is being signed to the party attempting to do the signing, in some
unambiguous form (e.g., no invisible fonts - it would provide you with a
high degree of assurance that you had actually seen every bit of what you
were signing). The signing party would indicate assent to what was in the
text. The notary might, or might not - depending on the "means for signing" -
note that some of the online click-thru "contracts" have been making
attempt to address this area; rather than simple "i agree"/"disagree"
buttons ... they put little checkmarks at places in scrolled form
.... you have to at least scroll thru the document and click on one or
more checkmarks .... before doing the "i agree" button. a digital
signature has somewhat higher integrity than simple clicking on the "i
agree" button ... but wouldn't subsume the efforts to demonstrate that
a person was required to make some effort to view document. Of course
in various attack scenarios ... simple checkmark clicks could be
forged. However, the issue being addressed isn't a forging attack
... it is person repudiating that they read the T&Cs before hitting
the "I agree" button.
With the depreciating of the non-repudiation bits in a long ago, and
far away manufactured certificates (which has possibly absolutely no
relevance to the conditions under which digital signatures are
actually performed) .... there has been some evolution of
non-repudiation processes. An issue for the non-repudiation
processes is whether or not the person actually paid attention to what
they were "signing" (regardless of the reason).
An issue for relying parties is not only was whether or not there was
some non-repudiation process in effect, but also does the
relying party have any proof regarding a non-repudiation
process. If there is some risk and/or expense associated with
repudiation occurring (regardless of whether or not it is 3rd party
fraud/attack issue), then a relying party might adjust the factors
they use for performing some operation (i.e. they might not care as
much if it is a low-value withdrawal transaction for $20 than if it
was a withdrawal transaction for $1m).
some physical contracts are now adding requirement that addition to
signing (the last page), that people are also required to initial
significant paragraphs at various places in the contract.
Using crypto against Phishing, Spoofing and Spamming
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 21 Jul 2004 10:10:24 -0600
To: "Steven M. Bellovin" <smb@xxxxxxxx>
Subject: Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: Ian Grigg <iang@xxxxxxxx>, EKR <ekr@xxxxxxxx>,
Florian Weimer <fw@xxxxxxxx>, cryptography@xxxxxxxx
At 01:54 PM 7/19/2004, Steven M. Bellovin wrote:
It's also worth remembering that an SSL-like solution -- cryptographically
protecting the transmission of credit card number, instead of digitally
signing a funds transfer authorization linked to some account -- was
more or less the only thing possible at the time. The Internet as a
medium of commerce was too new for the banks to have developed
something SET-like, and there wasn't an overwhelmingly-dominant client
platform at the time for which custom software could be developed.
(Remember that Windows 95 was the first version with an integral TCP/IP
stack.) *All* that Netscape could deploy was something that lived in
just the browser and Web server. SET itself failed because the
incentives were never there -- consumers didn't perceive any benefit to
installing funky software, and merchants weren't given much incentive
to encourage it.
SET couldn't replace online transaction ... the encryption was
effectively there for hiding credit card while in-flight ... which
SSL was already doing ... but SET was doing at an order to two-orders
increase in complexity and overhead. SET didn't provide any
additional countermeasure against the major exploits/vulnerabilities
(vis-a-vis SSL) ... even with all that complexity.
the transaction was still online ... since there are a bunch of other
factors involved in authorization ... like credit limit ... not just
whether there is impersonation with lost/stoleln numbers.
there was still the enormous payload bloat (certificates and
signatures increase the size of typical 8583 transaction by two-orders
of magnitude) which prevent true end-to-end security operation. As a
result the signature was verified at some internet boundary, then the
signature and certificate(s) were stripped off and traditional 8583
packet forwarded to the consumer/issuing financial institution. Later
at some ISO standards meeting, one of the association business people
presented numbers on number of 8583 packets with the signature bit
turned on and they positively knew no digital signature was involved.
It wasn't even a real PKI ...
1) i.e. the x.509 identity certificates from the early 90s had been
depreciated because of the privacy and liability issues ... and the
certificates effectively were issuing relying-party-only certificates
with the account number and public key.
2) there was no revocation and/or other types of process (which could
be considered minimum requirement for a PKI operation) ... they were
simply manufactured certificates (a term we coined to describe the SET
and SSL infrastructure; contrasting it to PKI). SET specifically
stated that the transaction would be online and rely on the existing
online infrastructure for determining lost, stolen, revoked, canceled,
etc ... as well as all the other stuff an online infrastructure can do
with timely and aggregated information (like credit limit)
3) it is trivial to show that for relying-party-only certificates
requiring online infrastructure ... that the certificates themselves
are redundant and superfluous ... aka the key is registered with the
issuing party ... and the transaction is performed by the issuing
party. The transaction can be digitally signed (w/o the enormous
payload bloat of carrying a certificate) and the issuing party verify
the digital signature with an onfile public key .... w/o having to
resort to dealing with a certificate (that the issuing party would
have originally generated from the onfile information).
From an incentive standpoint the PKI model is effectively orthogonal
to standard business processes.
The key owner pays something to the issuing party (or at best, the
issuing party absorbs the costs). The standard business process has
any sort of contract between the key owner and the issuing party.
This totally leaves out the relying-party ... which is the primary
beneficiary of the PKI model from being a part of the contractual
business process ... which would imply little or no legal recourse if
something went wrong. GAO has created a facade to address this issue
by making the TTP certification authorities sort of agents of the GAO
... and having all relying-parties signed contracts with the GAO., The
PKI frequently creates a total disconnect between the parties of the
certification "contract" ... and the relying parties ... which should
have recourse in case something went wrong aren't even a part of it.
In the specifics of the SET deployment ... the primary potential
beneficiaries theoretically were the merchants (from the thoery that
SET signed transactions would be considered card-present & card-owner
present ... and lower the merchants cost for doing the transactions).
However the parties "paying" for the certificates and most of the
infrastructure were the issuers and the consumers. Not only may a
traditional TTP PKI create legal disconnect for relying parties
.... but in the SET case there was major disconnect between who paid
for most of the infrastructure and who benefited (i.e. need some sort
of mechanism to get the merchants to pay for the consumer's
certificate .... even tho the certificates were functionally redundant
and superfluous).
dual-use digital signature vulnerability
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 22 Jul 2004 08:34:25 -0600
To: Amir Herzberg <herzbea@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: Barney Wolff <barney@xxxxxxxx>, Anton Stiglic <astiglic@xxxxxxxx>,
cryptography@xxxxxxx
At 05:37 AM 7/22/2004, Amir Herzberg wrote:
Most (secure) signature schemes actually include the randomization as
part of their process, so adding nonces to the text before signing is
not necessary. OTOH, I don't see any problem in defining between the
parties (in the 'meta-contract' defining their use of public key
signatures) that the signed documents are structured with a random
field before and after the 'actual contract', as long as the fields
are well defined.
there has been some claim that large random nonces as part of message
... before hashing and signing is characteristic of RSA
signatures. one of the issues with DSA and hardware tokens in the 90s
was that none of the hardware tokens had reliable random
generators. If you were doing DSA (or ECDSA) infrastructure ... then
integrity was dependent on quality random generator as part of the
signature process (to preserve the integrity of the private key). In
some sense, large random nonces (as part of the content to be signed)
was shifted to the party(s) generating the message as part of the RSA
process. In theory, DSA/ECDSA eliminates that requirement
... especially as you move in to the late 90s where hardware tokens
started to appear that had quality random generators.
protocols have had servers contributing unique values in signed
messages .... in things like authentication protocol .... as
countermeasure to replay attacks (on the server).
protocols have had clients contributing some values in signed messages
... in an authentication protocol ... as countermeasure of server
attacks on clients. It isn't necessary that the client contributed
part has to bracket both the start and end of the message .... in a
digital signature environment ... since the digital signature protects
the whole message integrity. The client contributed part could be
simple readable text disclaimer ... comparable to some disclaimers you
see at the bottom of emails (especially from lawyers, doctors, and/or
people that work for such firms .... you even see it in various
mailing lists by people that work for the big accounting firms).
sometimes the recommendations are that both server and client
contribute something unique to the signed message ... as generic
countermeasures ... regardless of whether the situation is actually
vulnerable to the associated attacks. In general, where the server
incurs some expense and/or liability associated with every message
... the server (or relying-party) is probably interested in
countermeasures against replay attacks.
one of the requirements given x9a10 working group (for the x9.59
protocol) ... was to be able to perform the operation in a single
round-trip .... w/o any sort of protocol chatter. this is comparable
to existing electronic payment business process. the countermeasure
that the infrastructure uses for replay attacks is to have the
transactions time-stamped and log is kept. transactions with
time-stamps that predate the log cut-off are deemed invalid. In the
x9.59 transaction scenario ... the signing entity (in theory)
specifically approved every transactions and used ecdsa signature. the
ecdsa signature would preserve the integrity of the transaction. the
time-stamp in the transaction would indicate whether it was within the
current active log window of the payment processor, and the randomness
of the ecdsa signature would provide uniqueness (two transactions that
were otherwise identical (in amount, time, etc) would be unique if
they had different ecdsa signatures (effectively provided by the
definition of dsa & ecdsa).
the addition of ecdsa signature to existing payment transaction
.... exactly preserved all the existing business processes and flows
... including the requirement that the client can originate the
transaction and the message flow could complete in a single
round-trip.
the addition of the ecdsa signature added
- 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
https://www.garlic.com/~lynn/2001h.html#61
so the x9.59 approach was to eliminate shared-secret as a business
characteristic of the account numbers used in x9.59 transactions.
https://www.garlic.com/~lynn/x959.html#x959
if an account number used in an (digitally signed) x9.59 transaction
... can only be used in x9.59 (digitally signed) transactions .... it
no longer carries with it the shared-secret characteristic
(since simple knowledge of the account number is insufficient to
impersonate and/or perform fraudulent transactions). So if the
insiders at a merchant processing end-point (or an external outsider
that is harvesting merchant processing transaction files) is able to
"steal" the account number but is not able to use it fraudulently
... it no longer has to be protected as a shared-secret.
The end-point static harvesting of transaction files has been the
major vulnerability for a long time. They have tended to be in the
clear because of the large number of business processes that require
access to the transactions. Neither SET nor SSL provided any
countermeasures for this (the major) vulnerability/exploit.
X9.59 did eliminate this as a vulnerability ... since stealing the
transaction file and harvesting the account numbers .... would not
provide the crook any mechanism to impersonate and/or perform a
fraudulent transaction. It turns out the secondary effect was that it
was no longer necessary to hide the account number while in flight
either (in order to preserve an account number as a
shared-secret). digitally signing the transaction both preserved the
integrity of the transaction as well as authenticating the origin of
the transaction. This then eliminated the requirement to hide the
account number as a countermeasure against the account number being
exposed (and comprimising its shared-secret characteristic).
The issue with SET was that it was horribly more complex and expensive
and provided no fundamental additional protection/countermeasure than
existing SSL (with respect to reducing existing vulnerabilities and
fraud). This was somewhat orthogonal to the problem with the horribly
additional expense not being born by the primary benefiting parties.
X9.59 is an enormously simpler and less expensive protocol than either
SET or SSL ... and turns out to address (in a business way) the major
exploits and vulnerabilities in the existing infrastructure ... the
basic characteristic that the account number is effectively a
shared-secret (which neither SET nor SSL addresses). Furthermore, with
the elimination of the shared-secret attribute for account numbers
.... then it is no longer necessary to encrypt the transmissions (for
purposes of preserving the account number secrecy).
https://www.garlic.com/~lynn/subpubkey.html#privacy
Using crypto against Phishing, Spoofing and Spamming
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 22 Jul 2004 13:07:30 -0600
To: Ed Gerck <egerck@xxxxxxxx>
Subject: Re: RP -- Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: cryptography@xxxxxxxx
At 01:39 PM 7/21/2004, Ed Gerck wrote:
The PKI model is not tied to any legal jurisdiction and is not a
business process. What is meant then by relying-party (RP) and RP
Reliance in X.509 and PKIX? I hope the text below, from a work in
progress submitted as an IETF ID, helps clarify this issue.
the TTP (trusted third party) PKI business model typically described
in the early 90s ... had a business exchange between a key owner and a
certification authority ... where the key owner paid the certification
authority for the issuing of a certificate that bound some information
to the public key. The payment of money by the key owner to the
certification authority created some sort of legal relationship
between the key owner and the certification authority .... with regard
to the certificate.
in that environment .... the key owner then digitally signed
something, and sent the something with a digital signature and the
certificate to a relying-party. The relying-party was frequently
assumed to be making some sort of legal reliance and recourse on the
performance of the certification authority. However, w/o payment of
funds and/or other legal arrangement between the relying-party and the
certification authority .... there was no legal bases for reliance
(unless mandated outside of traditional business context by some
gov. mandate)
it appears that the GAO .... working within that semantic & structural
business context ... has taken some effort to create a legal basis for
reliance and recourse between the relying parties and the
certification authorities for the federal PKI . It basically has
something along the lines of the certification authorities signing a
contractual relationship with the GAO. Then all the relying parties
also sign a contractual relationship with the GAO .... then there is
recourse for the relying parties on certification authority
performance based on the relying parties contract with GAO (for
certification authority performance) and the GAOs contract with the
certification authorities (for certification authority
performance). This is sort of trying to get around the lack of any
implied performance and/or contractual relationship (and therefor
recourse) because the relying parties haven't actually paid any money
to the certification authorities.
In the simple case, having any sort of legal obligation between the
certification authority and the key-owner ... and any sort of totally
different legal obligation between the key-owner and a relying party
... normally would fail to create any sort of legal obligation between
(the traditional TTP PKI) certification authorities (described in the
early 90s) and the set of relying parties.
some of this became mute by the mid-90s with the observation that the
traditionally considered identity x.509 certificates represented a
significant privacy and liability exposure ... and the retrenching by
infrastructures to relying-party-only certificates (effectively
account number and public key ... although even a relying-party-only
SET certificates could represent a factor of 100-times payload
bloat). the other issue that quickly became observed if the
relying-party and the certification authority were the same .... then
the relying party would typically have a large superset of the
information that they included in any relying-party-only certificate
... and that having the key-owner to return this small subset of
information repeatedly to the relying-party (/certification authority)
was redundant and superfluous .... other than possibly contributing
huge computational and transmission overheads for no useful purpose.
https://www.garlic.com/~lynn/subpubkey.html#rpo
IETF standards tend to be descriptions of protocol and parties role in
the protocol. Such syntactical and semantical description of the
protocols has rarely included description of any possible syntactical
and semantic business relationships .... especially of the typical
kind being proposed in the early 90s for TTP certification
authorities.
for pkix references .... see
https://www.garlic.com/~lynn/rfcietff.htm
and click on Term (term->RFC#) in the RFCs listed by section
then click on "PKI" in the Acronym fastpath section.
the current results:
public key infrastructure (PKI)
see also authentication , encryption , public key
3820 3779 3778 3770 3741 3739 3709 3653 3647 3562 3447 3379 3354 3335
3281 3280 3279 3278 3275 3174 3163 3161 3156 3126 3125 3110 3076 3075
3039 3029 2986 2985 2943 2931 2898 2847 2807 2803 2802 2797 2726 2693
2692 2587 2585 2560 2559 2537 2536 2535 2528 2527 2511 2510 2459 2440
2437 2404 2403 2385 2315 2314 2313 2311 2202 2154 2137 2085 2082 2065
2025 2015 1991 1864 1852 1828 1810 1751 1544 1424 1423 1422 1421 1321
1320 1319 1186 1115 1114 1113 1040 989
clicking on any RFC number will bring up the RFC summary in the lower
frame. Clicking on the ".txt" field in the RFC summary will fetch the
actual RFC.
E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: cryptography@xxxxxxxx
Subject: E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
Date: Fri, 23 Jul 2004 09:04:33 -0600
E-commerce attack imminent; Sudden increase in port scanning for SSL
doesn't look good.
http://www.techworld.com/security/news/index.cfm?NewsID=1975
... aka not necessarily an attack on SSL itself ... but identifying
end-points with open SSL ports as attack targets i.e. end-points with
open SSL ports are likely to be somewhat higher value targets than
machines w/o SSL ports .... since the operators possibly feel they
have something to protect.
E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
Date: Fri, 23 Jul 2004 12:08:29 -0600
To: Matt Crawford <crawdad@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
Cc: cryptography@xxxxxxxx
At 11:09 AM 7/23/2004, Matt Crawford wrote:
I can't see any reasonable way to derive your conclusion from the cited article.
"The surge began on 15 July, the day before the public disclosure
of a critical flaw in a server module called mod_ssl."
"The last time Netcraft observed similar activity was in April,
shortly before a wave of attacks on SSL servers that included the
compromise of some major e-commerce sites. Attackers used a flaw
in Microsoft's implementation of SSL to install malicious code..."
i just mentioned that it could possible be (another kind of)
attack/threat model (other than the obvious referenced
in the article).
i wasn't aware that this mailing list would preclude mention
of other possible attack/thread models .... other than the
obvious ones mentioned.
E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 23 Jul 2004 13:34:22 -0600
To: Matt Crawford <crawdad@xxxxxxxx>
Subject: Re: E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
Cc: cryptography@xxxxxxxx>
slightly more topic drift w/respect to potential/possible threat
models ...
i have put quite a bit of work into security taxonomy as part of the
merged securitity glossary and taxonomy
https://www.garlic.com/~lynn/index.html#glosnote
i've relatively recently taken a pass at the cve database ...
http://cve.mitre.org/cve/index.html
http://www.osvdb.org/
but what I found was very little structure. i have done word frequency
analysis on the descriptions ... but even that isn't really conclusive
(since effectvely random people are generating quite random word
descriptions). I was hoping to find more structure for expanding
taxonomy for threat models, vulnerabilities, and exploits.
E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Matt Crawford <crawdad@fnal.gov>
Cc: cryptography@xxxxxxxx
Subject: Re: E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
Date: Fri, 23 Jul 2004 18:18:40 -0600
here is another article on the same subject
http://thewhir.com/marketwatch/ssl072304.cfm
which includes the following quote
According to Netcraft, SSL, which is used to encrypt sensitive
information for e-commerce transactions, points to the presence of
sensitive financial data that hackers would be interested in stealing.
which might plausibly be interpreted as attackers associating
the presence of an open SSL port as indicating a server/endpoint
worthy of attack.
dual-use digital signature vulnerability
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 25 Jul 2004 13:41:56 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
Subject: Re: dual-use digital signature vulnerability
Cc: cryptography@xxxxxxxx, sws@xxxxxxxx, astiglic@xxxxxxx
At 07:07 PM 7/24/2004, Peter Gutmann wrote:
A depressing number of CAs generate the private key themselves and mail out to
the client. This is another type of PoP, the CA knows the client has the
private key because they've generated it for them.
one could claim that there might be two possible usage scenarios,
involving two different threat models: encryption and authentication.
from a business standpoint the encryption of corporate data
(especially data at rest .... which might include some of the
corporate jewels) can represent single point of failures ... if
private key is required for the recovery of corporate jewels and the
private key isn't reliably replicated (to avoid single points of
failure); then there is a serious, corporate, overriding availability
threat.
the claim can be made that the trade-off for authentication and
digital signature would result in no escrow nor replication of private
key .... since the overriding threat model is a) impersonation and/or
b) not being able to reliably attribute certain actions to specific
people.
the assertion here is possible threat model confusion when the same
exact technology is used for two significantly different business
purposes.
.... in general, no key escrow or no key replication is frequently bad
in the encryption business process scenario
... while no key escrow or no key replication is good in the
authentication/digital signature business process scenario.
a problem arises when the business purpose uses of the public/private
key pair isn't sufficiently described ... leading to confusion (and/or
the same public/private key pair are used for different business
processes with possibly conflicting threat models).
dual-use digital signature vulnerability
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 26 Jul 2004 14:26:01 -0600
To: Richard Levitte - VMS Whacker <levitte@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: pgut001@xxxxxxxx, cryptography@xxxxxxxx,
sws@xxxxxxxx, astiglic@xxxxxxxx
At 02:00 PM 7/26/2004, Richard Levitte - VMS Whacker wrote:
That's all and well, but I can't see why that would be interesting to
a generic, third-party CA. If you're talking about a CA within the
same corporation, then I can understand, since they usually (as far as
I can guess) work from a different standpoint and with different
priorities.
What you describe feels to me like encryption is ill understood and
placed in the hands of random individuals. If you want safety and
recoverability, there's nothing like one or several backups, maybe
protected with different means (different encryption, different
storage media (including vaults), different keys, and so on).
I believe there was at least one large institutional effort where keys
were generated, escrowed and loaded into hardware tokens and
distributed. the persons were expected to use the hardware tokens for
both authentication and encryption. if the hardware token failed (like
if the battery died), they could get a new hardware token issued with
the same keys.
the obviously needed the original keys if they had used the hardware
token for encryption (of data that turned out to be laying around
someplace).
however, it wasn't necessary to have escrowed keys for authentication,
simply issuing a new hardware tokens with new (authentication) keys
would have been sufficient (and reregistering the new public key).
here is an issue where, if they're using hardware tokens for key
protection ... they really need to distinguish between encryption
keys and authentication keys .... either a single hardware token with
two different sets of keys ... and the token knows how to
consistently differentiate their use between encryption and
authentication ... or two different hardware tokens ... consistently
used for the different (business) purposes.
there is a side issue with institutional delivered hardware tokens ...
and if they were to replace existing shared-secret pins/passwords ...
where a person might have a hundred unique shared-secrets for their
various electronic relationships .... and potentially be issued at
least one hardware token to be used in lieu of every pin/password
... and potentially a second hardware token for encryption only
purposes (say in dongle form ... a key chain with 100-120 or dongles
... in need of medium sized ruck sack just to lug them around).
In Search of Eve - the upper boundary on Mallory
From: lynn@xxxxxxxx
Date: July 24, 2004 01:05 pm
To: Financial Cryptography
Subject: In Search of Eve - the upper boundary on Mallory
here are two separate threats ... one carried over from the real world
... and one ... somewhat unique to the internet.
in the real world ... people that are dealing with unknown entities,
don't really care who they are ... they care whether they can be
trusted. this is the better business bureau model. certificates for
this purpose didn't really fly on the internet because almost all
transactions are done with known entities ... repeat business and/or
extremely well known operations. They didn't need a certificate
attested to whether they could be trusted. The other five percent of
the transactions are spread over millions of commercial websites
... and it was/is difficult to drum up a revenue model that would
cover reputation certificates. ebay is somewhat addressing this with
reputation scoring.
the other issue is that you are dealing with somebody you know
.... but because the communication is thru a untrusted and possibly
hostile network ... can you really be sure that it hasn't been
subverted. PGP has a model that covers this .... you acquire the
public key and validate with some out-of-band process. This handles
all of the entities that you frequently deal with &/or know.
This is effectively what has been for some number of commercial
entities called certification authorities which have had their public
key preloaded in browsers (before they are shipped) .... it is the PGP
model ... but the out-of-band mechanism is having the public keys
preloaded by the browser manufacture.
For commercial entities .... a PGP browser could be preloaded with a
better business bureau public key. The better business bureau could
maintain a table of registerd & trusted commercial entities ... along
with their public keys and URLs. You can perodically download the
latest table from the better business burear website.
So one question ... is it easier for the general public to understand
... if instead of describing the paradigm with analogies to the
certificate model .... is it easier to describe it as a PGP model
where the person loads other entities public keys (i.e. their
signature verification mechanism) and uses out-of-band process to
guarantee that they have the correct signature verification mechanism.
It might be easier for the general public to relate to a signature and
a signature verification methodology. That is much closer to what they
currently experience. Trying to get the general public to relate to a
certificate description paradigm .... (including self-signed
certificate description) that has a couple layers of (unecessary)
indirection ... would seem to be a much harder task
In Search of Eve - the upper boundary on Mallory
Refed: **, - **, - **, - **
From: lynn@xxxxxxxx
Date: July 27, 2004 10:59 AM
To: Financial Cryptography
Subject: In Search of Eve - the upper boundary on Mallory
Long ago and far away we were asked to work with this small
client/server startup that wanted to do payments on the server. In the
year that we worked with them, they moved from menlo park to mountain
view and changed their name from mosaic to netscape. minor
references:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
out of this work came something called a payment gateway and
electronic commerce. along the way we had to do various kinds of
detailed due diligence on some number of the major things called
certification authorities.
While the certification authorities were doing all sorts of integrity
things ... it basically came down to making sure that the domain name
you typed into your browser in some way related to the domain name of
the server you were talking to.
This is significantly different "trust" issue from merchants taking
credit card payments. For a merchant to take credit card payments, a
merchant/acquiring financial institution has to take financial
liability for the merchant ... and typically every transaction passes
thru some processs related to that merchant financial institution
before it gets to the consumers' bank.
With respect to the earlier post on this topic, we actually spent
quite a bit of effort on certificates that had more meaning than
whether the domain names match ... and weren't able to come up with a
viable business scenario.
In theory, there is a requirement for trust for entities that have
never dealt before. BBB, gov. & non-gov. licensing agencies provide
some of this in the physical world.
In fact, various BBB and licensing agencies have looked at providing
online, realtime trust information (as opposed to offline stale,
static certificate oriented solutions) ... aka moving the paper
certificates (hung on some wall) paradigm into an online 1990s
paradigm ... as opposed to the PKI model that wants to preserve the
pre-1990 offline paradigm with simple substitution of electronic bits
for the paper.
The issue of the paper certificates in the pre-1990, real world
... was that there really wasn't a practical way of doing a realtime
check with the authoritative agency issuing the certificate (hanging
on the wall). To some extent, the PKI model is emulating the pre-1990,
offline real world paradigm ... but substituting electronic bits for
paper. However, with the emerging 1990, online world .... it is now
frequently possible to go agency web sites and check realtime status.
to some extent this is the ebay model ... maintaining realtime
information/history about parties active on ebay.
In Search of Eve - the upper boundary on Mallory
From: lynn@xxxxxxxx
Date: July 27, 2004 11:09 AM
To: Financial Cryptography
Subject: In Search of Eve - the upper boundary on Mallory
The comment about repeat business vis-a-vis first time business was
based on paying for a trust infrastructure with something like
transaction charges.
However, it turns out that something like 90-95 percent of the
transactions are repeat transactions and/or with small number of
extremely well known operations.
That leaves millions of commerce sites and possibly five percent (or
less) of the transactions that are most in need of a trust
infrastructure. So each of these millions of commerce sites are each
making a couple bucks a month off their commerce sites ... and, as a
result, for each of these commerce sites there isn't a very large
value proposition for paying for a trust operation.
The issue isn't whether or not a trust infrastructure is required for
such market segment ... but working out a value proposititon to cover
the costs of a trust infrastructure.
should you trust CAs? (Re: dual-use digital signature vulnerability)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 28 Jul 2004 14:35:42 -0600
To: Adam Back <adam@xxxxxxxx>
Subject: Re: should you trust CAs? (Re: dual-use digital signature vulnerability)
Cc: Michael_Heyman@xxxxxxxx, cryptography@xxxxxxxx
At 12:09 PM 7/28/2004, Adam Back wrote:
The difference is if the CA does not generate private keys, there
should be only one certificate per email address, so if two are
discovered in the wild the user has a transferable proof that the CA
is up-to-no-good. Ie the difference is it is detectable and provable.
If the CA in normal operation generates and keeps (or claims to
delete) the user private key, then CA misbehavior is _undetectable_.
Anyway if you take the WoT view, anyone who may have a conflict of
interest with the CA, or if the CA or it's employees or CPS is of
dubious quality; or who may be a target of CA cooperation with law
enforcement, secrete service etc would be crazy to rely on a CA. WoT
is the answer so that the trust maps directly to the real world trust.
(Outsourcing trust management seems like a dubious practice, which in
my view is for example why banks do their own security,
thank-you-very-much, and don't use 3rd party CA services).
In this view you use the CA as another link in the WoT but if you have
high security requirements you do not rely much on the CA link.
in the case of SSL domain name certificates ... it may just mean that
somebody has been able to hijack the domain name ... and produce enuf
material that convinces the CA to issue a certificate for that domain
name. recent thread in sci.crypt
https://www.garlic.com/~lynn/2004h.html#28 Convince me that SSL certificates are not a big scam
the common verification used for email address certificates (by
certification authorities) ... is to send something to that email
address with some sort of "secret" instructions. so the threat model
is some sort of attack on email from the CA ... snarf the user's
ISP/webmail password and intercept the CA verification email. (it
simply falls within all the various forms of identity theft ... and
probably significantly simpler than getting a fraudulent driver's
license). with the defense that it is possibly another form of
identity theft .... say you ever actually stumbled across such a
fraudulently issued certificate .... it would probably be difficult to
prove whether or not the certification authority was actually involved
in any collusion. even discounting that there is no inter-CA
certificate duplicate issuing verification .... there are enuf failure
scenarios for public/private keys .... that somebody could even
convince the same CA to issue a new certificate for the same email
address (even assuming that they bothered to check)
Any TLS server key compromises?
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 16 Aug 2004 13:54:45 -0600
To: Marc Branchaud <marcnarc@xxxxxxxx>
Subject: Re: Any TLS server key compromises?
Cc: cryptography@xxxxxxxx
At 02:34 PM 8/12/2004, Marc Branchaud wrote:
I've been wondering, has a TLS server (or client, for that matter) key
ever actually been compromised? I don't think I've ever heard of one.
I'm thinking of two possible avenues for compromise, and ignoring
insider attacks. One is through defects in the protocol itself or its
implementation. The other would be through a compromise of the server
host (e.g. a buffer overflow in Apache) that allows the attacker to
copy the TLS server's private key from the file system.
It seems to me that in-the-wild attacks on the protocol or its
implementation are unheard of.
OTOH, we hear about server break-ins all the time. However, one never
hears about these break-ins leading to a compromise of the server's
key.
Perhaps the server's private key isn't a really useful target?
Although posession of the key makes it easy to spoof a secure server,
actually doing that spoofing requires a secondary attack, like
phishing or an active attack on the Internet, to redirect a user to
the false server.
So have there ever been any actual TLS private key compromises
(through any non-insider attack)?
If TLS private keys aren't attractive enough a target for them to be
compromised even when the opportunity presents itself (as I'm assuming
it has), then to what extent do these keys really need to be
protected?
One of the issues is some prior implication that at least some of the
SSL/TLS port knocking was helping identify sites that might be
indicative of something to protect. Lets say somebody finds some
really juicy financial targets using the technique.
So the server is penetrated and the attacker is presented with two
files .... one with the private key .... and one with a million
financial transactions ... which would they be more likely to
take?
I would assert that the million financial transactions file .... yield
possibly couple hundred thousand accounts numbers that could then be
used directly in fraudulent transactions. The SSL/TLS private key just
says that you have to put in some evesdropper in on the server's
SSL/TLS sessions, decrypt the traffic and decide what it means. While
it may be of some academic interest ... it would seem that letting the
server keep on doing all that work for you ... and just harvesting the
results ..... represents a lot bigger return for effort.
Part of the issue is that the threat model for server file exploit is
frequently the same for the real data "at rest" and the private key
file (which is just protecting the real data while in transit) ... the
actual, real data can represent a lot higher immediate fraud
potential.
So lets say the attacker does take both files for the fun of it
.... but likely won't get around to any SSL/TLS evesdropping attacks
until exhausting all the other financial fraud possibilities (from
already having a huge number of account numbers). Even if they
eventually exhaust any current crop of fraudulently harvested account
numbers ... they will likely try the same attack on another server
... before they possibly decide that SSL/TSL evesdropping attacks are
worth the effort.
It is possible, the SSL/TSL private key file might be more attractive
target in non-financial sector circles (evesdropping for the sake of
evesdropping .... possibly for other than direct financial incentive).
You would probably start hearing about the client keylogger exploits
including any client private key file .... if client keys started
being used for any significant purposes .... aka current client
keylogger exploits are able to authenticate directly just from the
pin/password key capture. any migration to private key operations would
mean that the client keylogger attacks would also need the private key
file (with the pin/password capture then being used to decrypt the
private key file in order to use the private key for authentication).
RPOW - Reusable Proofs of Work
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 16 Aug 2004 16:31:58 -0600
To: "R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: RPOW - Reusable Proofs of Work
Cc: cryptography@xxxxxxxx
At 12:36 PM 8/15/2004, R. A. Hettinga wrote:
The new concept in the server is the security model. The RPOW server
is running on a high-security processor card, the IBM 4758 Secure
Cryptographic Coprocessor, validated to FIPS-140 level 4. This card
has the capability to deliver a signed attestation of the software
configuration on the board, which any (sufficiently motivated) user
can verify against the published source code of the system. This lets
everyone see that the system has no back doors and will only create
RPOW tokens when supplied with POW/RPOW tokens of equal value.
I got hit with exploits on 4758 cards ... in thread in sci.crypt
https://www.garlic.com/~lynn/2004j.html#2
RPOW - Reusable Proofs of Work
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 16 Aug 2004 16:50:13 -0600
To: "R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: RPOW - Reusable Proofs of Work
Cc: cryptography@xxxxxxxx
At 12:36 PM 8/15/2004, R. A. Hettinga wrote:
This is what creates trust in RPOWs as actually embodying their claimed
values, the knowledge that they were in fact created based on an equal
value POW (hashcash) token.
the issue in the yes card exploit is that you migrate the financial
business rules out into hardware tokens (of any kind) and then do
peer-to-peer operations between tokens.
the threat model is you attack the belief in a valid hardware token
... once you have that you have the mechanism for creating counterfeit
tokens that can convince other tokens that they are valid. These
counterfeit tokens don't tell the truth ... they are programmed to say
whatever will convince other tokens that can be trusted.
and as per previous post ... i got hit in a sci.crypt thread with the
claim that even 4758 can be successfully attacked.
misc. posts discussing yes card token attacks that 1) result in
being able to fabricate counterfeits 2) which are acceptable in
offline, peer-to-peer operations:
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
https://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
https://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
https://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
https://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
RFC 3833 Threat analysis of the domain name system (DNS)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: cryptography@xxxxxxxx
Subject: RFC 3833 Threat analysis of the domain name system (DNS)
Date: Wed, 25 Aug 2004 16:13:08 -0600
as always ... can go to
https://www.garlic.com/~lynn/rfcietff.htm
and either scroll down the summary page to the 3833 summary and then
retrieve the actual RFC by clicking on the ".txt=nnnn" field.
In this case it is also possible to click on Term (term->RFC#) in
the RFCs listed by section ... and then click on "DNSSEC" in the
Acronym fastpath section at the top. That brings up the DNSSEC
RFCs. ... where DNSSEC (and/or domain name security) appeared
somewhere in the title or abstract.
as a side note, I've just done about everything possible that I can do
with scanning actual RFCs for references. I did a pass ... where I
created a list of all RFCs ... where the scan didn't produce RFC
numbers from a reference section ... and then scanned those RFCs for
anything that looked like there might be a RFC number anywhere in the
body. Then I manually examined that list of RFCs for how they
formated/called the references section. somewhat more detailed
discussion of the references & md5 stuff:
https://www.garlic.com/~lynn/2004k.html#6
RFC 3833
Title: Threat Analysis of the Domain Name System (DNS)
Author(s): D. Atkins, R. Austein
Status: Informational
Date: August 2004
Mailbox: derek@xxxxxxxx, sra@xxxxxxxx
Pages: 16
Characters: 39303
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-dnsext-dns-threats-07.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3833.txt
Although the DNS Security Extensions (DNSSEC) have been under
development for most of the last decade, the IETF has never written
down the specific set of threats against which DNSSEC is designed to
protect. Among other drawbacks, this cart-before-the-horse situation
has made it difficult to determine whether DNSSEC meets its design
goals, since its design goals are not well specified. This note
attempts to document some of the known threats to the DNS, and, in
doing so, attempts to measure to what extent (if any) DNSSEC is a
useful tool in defending against these threats.
[anonsec] Re: potential new IETF WG on anonymous IPSec
Refed: **, - **, - **
Date: Mon, 13 Sep 2004 13:16:17 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: [anonsec] Re: potential new IETF WG on anonymous IPSec
Cc: cryptography@xxxxxxxx, eugen@xxxxxxxx
At 11:43 AM 9/11/2004, Peter Gutmann wrote:
So in other words it's the same baby-duck security model that's been
quite successfully used by SSH for about a decade, is also used in
some SSL implementations that don't just blindly trust anything with a
certificate (particularly popular with STARTTLS-enabled MTAs/MUAs
where you don't want to bother with CA-issued certs), and is even used
in various X.509 applications (via "certificate fingerprints"),
although the X.509 folks don't like to admit that because it implies
that a known-good cert fingerprint is more reliable than a CA :-).
i've referred to it as identity agnostic ... as opposed to anonymous
... even with public key use. the scenario is that the original
identity x.509 certificates created huge privacy issues.
the current credit card scenario, it carries a name ... in theory
so that the merchant or point-of-sale can cross-check the name against
additional forms of identification .... as a means of authentication
(where the merchant is sort of a stand-in agent for the consumer's
financial institution .... even tho the merchant and the consumer's
financial institution may have significantly different and possibly
opposing interests). in effect it is transforming something that
should be purely an authentication operation (is the entity entitled
to perform a transaction for the account) into a much more difficult
(and privacy invasive) identification operation.
the x9.59 scenario ....
https://www.garlic.com/~lynn/x959.html#x959
is that the transaction is simply authenticated with a digital
signature that the merchant passes thru to the consumer's financial
institution. the consumer financial institution verifies the digital
signature with public key on file for that account. the verification
of the digital signature implies some form of something you
have authentication (implies that you uniquely have the
corresponding private key).
it becomes a straight-forward authentication operation and identity
agnostic ... w/o the horrible identity and privacy invasive that can
accompany a x.509 identity certificate.
while it may be possible for various agents to associate the
authentication operation w/identities .... the operations themselves, at
least don't carry the possibly mandatory identity information &
privacy invasive information that can be found in identity x.509
certificates.
public-key: the wrong model for email?
Date: Wed, 15 Sep 2004 18:54:11 -0600
To: Ed Gerck <egerck@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: public-key: the wrong model for email?
Cc: <cryptography@xxxxxxxx>
At 12:39 PM 9/15/2004, Ed Gerck wrote:
[1] Public-key cryptography gives the impression that email message security can
be achieved quite simply. The public-key can be distributed at will, no need for
secrecy, and anyone can receive private and secure messages. The same procedure
being applied to each side, sender and receiver, both could immediately engage
in private and secure communication.
there are (at least) 2-3 characteristics of various public key systems
- 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 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:
https://www.garlic.com/~lynn/aadsm17.htm#12 A combined EMV and ID card
https://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
at 9/17/2004 10:50 pm, anders wrote:
In Sweden banks are combining the EMV payment application(s)
with a separate identity application using PKI. The reasons are
obvious, one card does it all.
The drawback is that the card holder's identity including social
security numbers etc. is available for any merchant terminal
to read if they want, as the public keys (certificates) are not
protected by PIN codes etc. If they were protected the card
would be incompatible with existing software and become
harder to use so that is not an option.
I would like to hear if anybody have heard of similar efforts
in other parts of the world.
Anders Rundgren
x9.99 privacy note
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/20/2004 10:45 AM
To: <internet-payments@xxxxxxxx>
Subject: x9.99 privacy note
x9.99 privacy impact assesement standard has been approved
http://www.x9.org
and the document should show up on the ansi electronic store before
too long
and the work item has been approved for iso tc68
https://web.archive.org/web/20021119011718/http://www.tc68.org/
https://web.archive.org/web/20030425064722/http://www.iso.ch/iso/en/stdsdevelopment/tclist/TechnicalCommitteeDetailPage.TechnicalCommitteeDetail?TC=68
there is some slightly related information .... i have a start at a
merged privacy glossary and taxonomy at
https://www.garlic.com/~lynn/index.html#glosnote
EMV cards as identity cards
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/20/2004 02:11 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: <internet-payments@xxxxxxxx>, Safecode <safecode@xxxxxxxx>
Subject: Re: EMV cards as identity cards
on of the issues in the account/identity fraud scenarios is that just
knowing the PAN .... allows fraudulent transactions to be performed.
you start to see things like harvesting of merchant transaction files
that provide PANs for fraudulent transactions. recent studies have
indicated that possible at least 77 percent of such harvesting
involves insiders.
part of the scenario is the security versus risk discussed in this
posting about merchant transaction file harvesting ans security
proportional to risk:
https://www.garlic.com/~lynn/2001h.html#61
one of the requirements given the x9a10 working group for x9.59
standard was to preserve the integrity of the financial infrastructure
for all retail payments. the resulting x9.59 standard
https://www.garlic.com/~lynn/x959.html#x959
uses digital signature to authenticate retail transactions (regardless
of kind, including iso 8583 payment transactions) but doesn't mandate
the horrendous payload bloat of attaching a redundant and superfluous
relying-party-only certificate.
x9.59 also specifies that account numbers that are used in x9.59
transactions can not be used in non-authenticated transactions. the
result is that it is no longer possible to perform fraudulent payment
transactions just by learning an account number. the scenario then is
that if it is no longer possible to perform fraudulent transactions by
harvesting (x9.59) account numbers from merchant transaction files
.... then it is no longer necessary to maintain such high security
infrastructures to prevent crooks from acquiring knowledge of account
numbers.
we've referred to this being privacy or identity agnostic .... as
opposed to truely anonymous. there is still an account number floating
around ... but typically has no other identifying information
... unless somebody gets a court order to acquire the information from
your financial institution. misc references to privacy, identity,
x9.59, etc
https://www.garlic.com/~lynn/subpubkey.html#privacy
misc. past postings mentioning privacy/identity agnostic:
https://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
https://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aepay7.htm#liberty Network Identity Alliance -- Liberty Alliance Project
https://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias
https://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/aadsm18.htm#22 [anonsec] Re: potential new IETF WG on anonymous IPSec
at 9/18/2004 11:32 pm anders wrote:
Paulo
I may have lost the safecode stuff.
I have no detailed description of EMV but that is probably easy to
get on the net.
But I essentially described a multi-application smart card which could
hold a credit-card function, a purse and in this case also an identity
function using PKI.
Since the card does not have a display or keyboard etc. there is no
way to select what resource the card reading app is to use. It is
therefore assumed that this is "hardcoded" into applications or that
applications offer this selection. However, you cannot do a selection
without having parts of the available resources accessible. In the
case of the ID-application it is actually your full identity!
To allow any merchant to monitor a card holder's identity is in
to some extent already possible due to the PAN code, but to *extend*
this "feature" seems to clearly be a step in the wrong direction.
Academics locked out by tight visa controls
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 20 Sep 2004 16:07:55 -0600
To: John Kelsey <kelsey.j@xxxxxxxx>
Subject: Re: Academics locked out by tight visa controls
Cc: <rah@xxxxxxxx>, cryptography@xxxxxxxx
At 08:03 AM 9/20/2004, John Kelsey wrote:
I guess I've been surprised this issue hasn't seen a lot more
discussion. It takes nothing more than to look at the names of the
people doing PhDs and postdocs in any technical field to figure out
that a lot of them are at least of Chinese, Indian, Arab, Iranian,
Russian, etc., ancestry. And only a little more time to find out that
a lot of them are not citizens, and have a lot of hassles with respect
to living and working here. What do you suppose happens to the US
lead in high-tech, when we *stop* drawing in some large fraction of
the smartest, hardest-working thousandth of a percent of mankind?
in '94 there was report (possibly sjmn?) that said at least half of
all cal. univ. tech. PHDs were awarded to foreign born. during some of
the tech green card discussions in the late '90s ... it was pointed
out that the internet boom (bubble) was heavily dependent on all these
foreign born .... since there was hardly enuf born in the usa to meet
the demand.
in the late 90s there were some reports that many of these graduates
had their education paid by their gov. with directions to enter an us
company in strategic high tech areas for 4-8 years .... and then
return home as tech transfer effort. i was told in the late 90s about
one optical computing group in a high tech operation .... where all
members of the group fell into this category (foreign born with
obligation to return home after some period).
another complicating factor competing for resources during the late
90s high-tech, internet boom (bubble?) period was the significant
resource requirement for y2k remediation efforts.
nsf had recent study on part of this
http://www.nsf.gov/sbe/srs/infbrief/ib.htm
graduate enrollment in science and engineering fields reaches new
peak; 1st time enrollment of foreign students drops
http://www.nsf.gov/sbe/srs/infbrief/nsf04326/start.htm
EMV cards as identity cards
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/21/2004 09:31 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: <internet-payments@xxxxxxxx>, <safecode@xxxxxxxx>
Subject: Re: EMV cards as identity cards
i have pointed out in multiple threads and numerous times (a number of
times when you have raised this or similar question in the past)
.... that there has been some history of x.509 identity certificates
from the early 90s and that the in the mid-90s, many financial
institutions around the world retrenched to relying-party-only
certificates .... because of the enormous privacy and liability issues
associated with the x.509 identity certificates.
I was at a presentation by one of the large german banks at the 1998
21st nissc conference in DC ... on the enormous privacy and liability
issues associated with x.509 identity certificates and the requirement
for relying-party-only certificates (effectively only containing an
account number and public key).
There were payment transaction designs and deployments from the
mid-90s that also used relying-party-only certificates and had made
some reference to the enormous privacy and liability issues associated
with x.509 identity certificates.
lots of past postings on relying-party-only certificates:
https://www.garlic.com/~lynn/subpubkey.html#rpo
the issue that i've also pointed out multiple times in the past is
that for online transactions involving replying-party-only
certificates, that the relying-party-only certificates can typically
be shown to be redundant and superfluous ... since the relying-party
is the issuing party ... and therefor already has a registered copy of
the public key (typically stored in an account record which will be
referenced as part of any online transaction).
the ancillary issue from some of the payment transactions from the
mid-90s using relying-party-only certificates for online iso 8583
payment transactions was that there was enormous payload bloat with
even various relying-party-only certificates being approximately two orders
of magnitude larger in size than typical base iso 8583 transaction.
there has also been some sporadic discussions that sometimes there is
confusion between identification and authentication and that there are
times that identification has been specified when authentication would
have been sufficient.
at 9/21/2004 12:27 am, anders wrote:
Exactly what are you addressing here???
1. That EMV is a bad idea since it (optionally) uses PKI?
Could very well be so but EMV is also an off-line thing as
the EMV founders incorrectly thought that not many countries
could afford broadband! Regardless how right of wrong this
assumption may be, those who actually are prepared to convert
to accepting chip-cards, probably have broadband as well.
That is, a core EMV idea is indeed ill-founded!
2. That ID certificates are redundant?
As ID certificates is an FI add-on service to be used by thousands
of independent e-gov relying parties using a common national identity
scheme, there is no viable alternative to PKI except using a gateway
approach which is fairly much the same trust wise. The difference
is that some people do not believe that gateways can sign but
schemes running in Norway shows that this is piece of cake.
At least technically!
Anders
EMV cards as identity cards
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/22/2004 10:11 AM
To :<internet-payments@xxxxxxxx>,
cc: <anders.rundgren@xxxxxxxx>, <safecode@xxxxxxxx>
Subject: Re: EMV cards as identity cards
possibly unrelated, random news, privacy related URL distributed today
about eu commission and the eu data protection act
http://iccheshireonline.icnetwork.co.uk/0100news/0200businessfarmingnews/tm_objectid=14663715&method=full&siteid=50061&headline=raid-threats-to-city-firms-name_page.html
there is also an issue with regard to what it means to "sign"
.... digital signatures as in authentication .... can be hardware tokens,
portals, etc. .... i.e. "signing" as part of some type of three factor
authentication:
https://www.garlic.com/~lynn/subintegrity.html#3factor
- 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:
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
semi-related to x9.99 privacy standard being passed (and should show
up at the ansi e-store shortly) and the new privacy work item being
approved for iso tc68 ... i also recently got an email notice that iso
sc6 has approved a new work item for the finread terminal
there was a related discussion in the sci.crypt newsgroup regarding
some of the requirements for legal signature (with some relationship
to feature/function in finread terminal, but happened to wander around
and cover a somewhat broader range of characteristics):
https://www.garlic.com/~lynn/2004h.html#48 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#50 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#52 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#53 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#54 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#55 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#56 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#57 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#59 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#2 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#4 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#9 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#10 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#11 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#12 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#13 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#14 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#15 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#19 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#20 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#22 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#23 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#25 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#27 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#0 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#1 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#3 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#8 New Method for Authenticated Public Key Exchange without Digital Certificates
An interesting "new" computer security problem
Date: Mon, 27 Sep 2004 12:58:31 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An interesting "new" computer security problem
Cc: cryptography@xxxxxxxx
note that was being done with virtual machines in the 60s .... well
before the orange book
there were also a number of commercial time-sharing companies offering
services based on virtual machine technology where possibly mutually
antagonistic clients were using the services.
we had a service that had some of the most sensitive corporate secrets
there were .... on the same machine with all sorts of BU, MIT, and
harvard students.
random past references to some of the in-house as well as commerical
(virtual machine based) time-sharing services from the 60s & 70s:
https://www.garlic.com/~lynn/submain.html#timeshare
At 11:03 PM 9/24/2004, Peter Gutmann wrote:
A few days ago I was chatting with some people working on a government
IT project who had a rather complex security problem that they needed
help with. They have a large number of users with Windows dumb
terminals (think Xterms but for Windows) connected to a central ASP
server, which runs various mutually untrusted apps from different
vendors. Their problem was that they needed a means of securing the
individual apps from each other.
I told them that they were in luck, and this exact problem had already
been addressed before. I'd drop off the detailed technical specs for
the solution when I next saw them, they could recognise it by its
bright orange cover.
Peter.
(Actually it wasn't quite that simple and easily solveable: The ASP
server is untrusted as well, it just acts as a middleman for back-ends
located at various locations, and only the back-ends are trusted. I
figured giving them the Orange Book would be easier than trying to
explain that they had an unsolveable problem on their hands).
An interesting "new" computer security problem
Date: Mon, 27 Sep 2004 13:51:36 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An interesting "new" computer security problem
Cc: cryptography@xxxxxxxx
for instance ... it wasn't exactly hidden that a certain gov. TLA was
very active in a particular vendor's user group organization .... and
in fact, had somebody that chaired some of the committees from
time-to-time.
look for installation code CAD in these virtual machine archives
(mostly from the 70s & 80s)
http://vm.marist.edu/~vmshare/
here is another organization from the late '70s (rather than the late
'60s):
https://www.garlic.com/~lynn/2001m.html#15
Credit card leaks continue at a furious pace
Refed: **, - **, - **, - **
From: Lynn Wheeler
Subject: Credit card leaks continue at a furious pace
To: <internet-payments@xxxxxxxx>
Date: Tue, 28 Sep 2004 09:09:18 -0600
Credit card leaks continue at furious pace
Security firm claims 120 million accounts compromised this year
http://www.msnbc.msn.com/id/6030057/
"We are writing you today to let you know that Visa recently informed
us of an unauthorized network intrusion," says a note sent earlier
this month by Washington Mutual bank to an undisclosed number of
consumers. "This network breach affects the security of your
Washington Mutual ATM/Visa Check Card."
... snip ...
slightly related ... security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
some mention of not being able to perform fraudulent transaction just
by knowing a (x9.59) pan ... in this long winded discussion about
dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#6
Phishing losses total $500 million - Nacha
From: Lynn Wheeler
Date: 09/29/2004 07:55 PM
To: <internet-payments@lxxxxxxxx>
Subject: Phishing losses total $500 million - Nacha
Phishing losses total $500 million - Nacha
http://www.finextra.com/fullstory.asp?id=12568
US payments association Nacha estimates the total monetary losses to
victims of phishing incidents nationwide may run as high as $500
million.
... snip ...
Fake Companies, real money; elaborate con wrings cash out of stolen credit cards
From: Lynn Wheeler
Date: 10/08/2004 03:12 PM
To: internet-payments <internet-payments@ls.fstc.org>
Subject: Fake Companies, real money; elaborate con wrings cash out of stolen credit cards
Fake companies, real money, Elaborate con wrings cash out of stolen credit cards
http://www.msnbc.msn.com/id/6175738/
T-Data, a small New-York based software company, doesn't take credit
cards -- never has in its 20-year history. But a few weeks ago, owner
Jeff Duhl found himself looking over $15,000 worth of credit card
charges seemingly accepted by his store.
... snip ...
... and a copy more while i'm at it ...
Corporate Identity Theft on the Rise
http://it.slashdot.org/it/04/10/08/1333219.shtml?tid=172&tid=187
"As millions of Americans lose their identities to online and offline
thieves, a new kind of crime has been cooked up by the criminals who
are not bothering with doing pesky credit card charges."
.. snip ...
Top reason for identity theft: stolen wallet
http://www.itfacts.biz/index.php?id=P1077
Exactly 15% of US consumers have been victims of identity theft, and
33% know a family or friend who has been, according to a new survey
from InsightExpress. A full 85% of respondents are concerned that
identity theft could happen to them. Most fear their identities could
be taken through a stolen wallet, and large percentages fear theft
through the Internet or stolen mail. Overall, 37% felt online
purchasing poses the greatest threat, followed by telephone purchases
(34%) and in-person purchases (10%).
... snip ...
How to store the car-valued bearer bond? (was Financial identity...)
Date: Sat, 23 Oct 2004 13:51:44 -0600
To: Ian Grigg <iang@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: How to store the car-valued bearer bond? (was Financial identity...)
Cc: Aaron Whitehouse <lists@xxxxxxxx>, cryptography@xxxxxxxx
somewhat the original design point for the EU stored-value smartcards
was an environment with poor, non-existent, and/or extremely expensive
online connectivity.
by contrast during the 90s, there was a big growth in stored-value
cards in the US that involved online transactions and where the
stored-value card was effectively just an authentication token.
in effect, the cost/benefit trade-off of the EU-based chips .... was
the cost of the chips enabling distributed offline transactions
against the poor, non-existent, and/or extremely expensive online
connectivity.
in the intervening years .... effectively a couple of things have
happened
1) growing world-wide ubiquitous online connectivity (significantly
mitigating being forced into having to do offline transactions
anywhere in the world)
2) increasing sophistication and ease of being able to counterfeit
both magnetic stripe authentication tokens ... as well as attacks on
the offline infrastructures where it is assumed that business rules
have been embedded in stored-value smartcard tokens in order to enable
offline transactions.
so now there is tendency for pushing chip tokens to address the ease
that magnetic stripe authentication tokens are being counterfeited ...
but that is quite orthogonal to the EU oriented stored value
smartcards targeted at enabling offline transactions (although
sometimes the two different objectives and solutions get confused
... because they both can involve hardware chip cards .... even tho
there is vast difference in using a hardware chip card for pure
authentication vis-a-vis having required business rules and logic in
hardware chip card for performing offline transactions).
Financial identity is *dangerous*? (was re: Fake companies, real money)
Date: Thu, 28 Oct 2004 12:21:32 -0600
To: Ian Grigg <iang@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Financial identity is *dangerous*? (was re: Fake companies, real money)
Cc: Alan Barrett <apb@xxxxxxxx>, cryptography@xxxxxxxx
At 03:31 PM 10/25/2004, Ian Grigg wrote:
:-)
It should be obvious. But it's not. A few billions
of investment in smart cards says that it is anything
but obvious.
To be fair, the smart card investments I've been
familiar with have been at least very well aware of
the problem. It didn't stop them proceeding with
papering over the symptoms, when they should have
gone for the underlying causes.
iang
my claim about the paradigm is that during the 80s, there was start of
lot of investment by all sorts of parties into smartcards ... targeted
for the portable computing market niche ... where the state of the art
would allow relatively powerful computing and memory in such chips
... but the technology didn't exist for portable input/output
technology .... as a result there also had to be ISO international
standards for the input/output stations that would interoperate with
the smartcards. that market niche started to disappear in the early
90s with the appearance of portable input/output technology associated
with cellphones and PDAs. by this time, at least several billion
dollars had been invested in the technology.
somewhat to recoup (at least some portion of) the investment, there
has been some searching for alternative market niches for the
technology. In the early 90s, my wife and I consulted to some agencies
on aspects of this. one such target was emergency medical information
.... a person could carry their complete medical records in such a
form factor .... and in a life&death emergency .... the emergency
crews could pull out the victims card and insert it into their locak,
offline, portable display technology and have access to the victims
complete medical records. The problem in this scenario was that an
emergency first responder isn't likely to be able to make use of the
victims medical records in offline manner. First off, if it is a real
emergency ... how does a first responder do other than
triage. Typically for anything that involves anything more complicated
... the first responder has to go online to "real" doctors at some
remote location. If you have a real online environment ... to real
(remote) doctors ... then a much better solution is to have something
that authenticates the victim ... and the consulting doctor then has
some mechanism for locating and retrieving the online medical records
(as opposed to first responder being able to make sense out of a
victim's complete medical records).
Another niche for the technology was offline financial transactions
... for parts of the world where online connectivity was difficult,
non-existent and/or extremely expensive. the smartcard would contain
the business rules and logic for performing (offline) financial
transaction interacting with random merchant terminals. Two issues
arise here .... there is a significant mutual suspicion (lack of
trust) problem between random merchant terminals anywhere in the world
and random consumer smartcards anywhere in the world; and the
technology started to be deployed at a time when online connectivity
was starting to become ubiquitous and easily available in most places
in the world. An example is the european deployed stored-value
(offline) smartcards in the 90s compared to the rapid market
penetration of stored-value (online) magstripe (gift, affinity,
merchant, etc) cards in the US .... making use of the ubiquitous
nature of online connectivity available in the US. Again, which the
availability of online .... the problem changes from requiring a very
expensive and trusted distributed offline infrastructure and offline
distributed business rules .... to the much more simple problem of
requiring (increasingly strong) authentication.
So the financial oriented infrastructure has seen some amount of
"skimming" threats and exploits with the terminals and/or
networks. Even if the smartcard paradigm is just reduced to a (dumb)
chipcard that only provides strong authentication .... the issue is
does the consumer completely provide their own environment ... or do
they have to depend on (and trust) randomly located terminals at
random locations around the world.
Part of the authentication issue ... is the 3-factor authentication
model
https://www.garlic.com/~lynn/subintegrity.html#3factor
- something you have
- something you know
- something you are
the "card" (or chip) provides the something you have piece.
in order to add something you know ... requires the consumer
entering a pin or password; the issue then becomes does the consumer
trust some randomly located pin-pad. there is a similar issue with
whether the consumer trust their own biometric sensor or would they
trust somebody else's biometric sensor.
a consumer owned cell phone .... could presumably provide both a
consumer trusted pin-pad ... and w/o a whole lot of magic ... a
consumer camera cell phone could be used for sensor for various kinds
of biometric info.
some part of the issue is that the original target market niche for
smartcards (portable computing with fixed interoperable input/output
stations) started to evaporate after a lot of the investment had been
done but before there was a lot of deployment and investment recovery.
Financial identity is *dangerous*? (was re: Fake companies, real money)
Date: Fri, 29 Oct 2004 07:55:07 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Financial identity is *dangerous*? (was re: Fake companies, real money)
Cc: cryptography@xxxxxxx
At 10:29 AM 10/28/2004, James A. Donald wrote:
Is there a phone that is programmable enough to store secrets on and
sign and decrypt stuff?
The ideal crypto device would be programmed by burning new proms, thus
enabling easy reprogramming, while making it resistant to trojans and
viruses.
there are a couple different trust relationships ... the issue of the
user trusting the keyboard/terminal ... and the issue of the relying
party trusting the keyboard/terminal.
The FINREAD terminal ... misc. (EU) finread references:
https://www.garlic.com/~lynn/subintegrity.html#finread
supposedly is certified as an stand-alone external keypad and display
that can't (very difficult) in being hacked. the financial scenario is
that the display can be trusted to display the amount being approved
.... the user puts in his card and enters their pin/password. The
pin-pad is certified as not being subject to virus keyloggers (that
you might find if a PC keyboard was being used).
For the relying party (say an online financial institution) ... the
user putting their card into the reader ... and the card generating
some unique value ... would indicate to the relying party something
you have authentication. The user entering a PIN can both indicate
something you know authentication as well as implying that the user
aggrees/approves with the value in the display.
Note that the implied agreement/approval ... in not just dependent on
the user entering the PIN ... but also on the certification of the
terminal ... that the terminal doesn't accept the PIN until after the
certified terminal displays the correct value (i.e. there is a
certified business process sequence).
The entering of the PIN can also involving transmitting some form of
the PIN to the relying party ... and/or the PIN is passed to the
smartcard/chip ... and the chip is known to only operate in the
appropriate manner when the correct PIN is entered. In this later
case, the relying party doesn't actually have knowledge of the
something you know authentication .... but the relying party can
infer it based on knowing the certified business process operation of
all of the components.
Lets say the unique value provided by the smartcard is some form of
digital signature ... and the relying party infers from the correct
digitial signature something you have authentication. There is still
the trust issue between the relying party and the terminal used by the
user .... which may also require that the (certified eu finread)
terminal also performs a digital signature .... in order for the
relying party to be able to trust that it really was a terminal of
specific characteristics ... as opposed to some counterfeit or
lower-trusted terminal.
There is still the issue of the user trusting such a terminal. If the
terminal belongs to the user .... in the user physical home space
.... then there isn't as much of a trust issue regarding the user
trusting the terminal.
The problem arises for the user if they are faced with using a
terminal in some random, unsecured location some place in the
world. Even in the situation where a relying party receives a valid
transaction with a valid digital signature from a certified, known
finread terminal ... there are still a number of MITM attacks on
finread terminals that might be located in unsecured locations
(various kinds of overlays and/or intermediate boxes capable of
performing keylogging and/or modified display presentation).
The personal cellphone and/or PDA ... with user "owned" display and
key entry .... is a countermeasure to various kinds of MITM attacks on
terminals in public &/or unsecured locations (user has no way of
easily proofing that they aren't faced with some form of compromised
terminal environment).
Adding reliability and trust to smartcards
Date: Sat, 30 Oct 2004 10:36:49 -0600
To: cryptography@xxxxxxxx
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Adding reliability and trust to smartcards
IST Results - Adding reliability and trust to smartcards
http://istresults.cordis.lu/index.cfm/section/news/tpl/article/BrowsingType/Features/ID/70511
of course ... reliability and trust is more than just the smartcards ... it assurance and trust related to the smartcard infrastructre ... not just the cards themselves.
recent posting on eal5 evaluation, somewhat related
https://www.garlic.com/~lynn/2004m.html#41 EAL5
other parts of the thread
https://www.garlic.com/~lynn/2004m.html#49 EAL5
https://www.garlic.com/~lynn/2004m.html#50 EAL5
semi-related posts about infrastructure
https://www.garlic.com/~lynn/aadsm18.htm#39 Financial identity is *dangerous*? (was re: Fake companies, real money)
https://www.garlic.com/~lynn/aadsm18.htm#40 Financial identity is *dangerous*? (was re: Fake companies, real money)
Payment Application Programmers Interface (API) for IOTP
Refed: **, - **, - **
From: Lynn Wheeler
Date: 11/06/2004 04:05 PM
To: internet-payments@xxxxxxxx
Subject: Payment Application Programmers Interface (API) for IOTP
recently published RFC
https://www.garlic.com/~lynn/rfcidx12.htm#3867
3867 I
Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP), Beykirch H., Hiroya M., Kawatsura Y., 2004/11/05 (106pp) (.txt=234572) (Refs 1738, 2246, 2801, 3538) (was draft-ietf-trade-iotp-v1.0-papi-06.txt)
clicking on the ".txt" field in the summary retrieves the actual RFC. clicking on any of the referenced RFCs goes to the summary for that RFC ... I got a request during Crypto 2004 for more complete indexing in the wake of trying to find all references related to MD5 ... so I finally got around to adding document refs to the summary field. and somewhat aside ... generated a brand new set of summaries just related to MD5
https://www.garlic.com/~lynn/rfcmd5.htm
this is another publication of the IOTP working group of the IETF. Long ago and far away the group started out as trying to map Mondex to Internet environment. Other works that the IOTP working group has done is ECML.
if you click on the actual RFC number in the summary, it brings up all the ways the RFC is indexed; i.e.
3867 - Internet Open Trading Protocol, application program interface
if you click on "Internet Open Trading Protocol", you get the list of all the RFCs from that working group (or at least the list since I started tracking/keeping RFCs by working group) ... aka:
Internet Open Trading Protocol
3867 3506 3505 3504 3354
and the respective summaries:
3506
Requirements and Design for Voucher Trading System (VTS), Eastlake D., Fujimura K., 2003/03/13 (15pp) (.txt=30945) (Refs 2801)
3505 I
Electronic Commerce Modeling Language (ECML): Version 2 Requirements, Eastlake D., 2003/03/13 (8pp) (.txt=13915) (Refs 2246, 2801, 3106)
3504
Internet Open Trading Protocol (IOTP) Version 1, Errata, Eastlake D., 2003/03/13 (6pp) (.txt=8655) (Refs 2801, 2802, 2803)
3354
Internet Open Trading Protocol Version 2 Requirements, Eastlake D., 2002/08/15 (6pp) (.txt=9671) (Refs 2246, 2801, 2802, 3106, 3275)
aka:
https://www.garlic.com/~lynn/rfcidx11.htm#3506
https://www.garlic.com/~lynn/rfcidx11.htm#3505
https://www.garlic.com/~lynn/rfcidx11.htm#3504
https://www.garlic.com/~lynn/rfcidx11.htm#3354
SSL/TLS passive sniffing
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 01 Dec 2004 11:47:37 -0700
To: Dirk-Willem van Gulik <dirkx@xxxxxxxx>
Cc: Ben Nagy <bnagy@xxxxxxxx>, cryptography@xxxxxxxx
Subject: Re: SSL/TLS passive sniffing
At 02:53 AM 12/1/2004, Dirk-Willem van Gulik wrote:
Access to the private key of the server cert gives you the ability to do
active sniffing and in some subset of cases passive sniffing. Access to
the session key (which requires the right permissions and access to the
httpd server) gives you passive sniffing.
It is not uncommon to set this up for customers in the commercial/banking
sectors to help them comply with certain audit requirements.
Note however that in each case it requires violating the web servers
security realm and/or storing something in two places. So technically it
may make much more sense to plug a module into each webserver itself with
a sufficiently secure agregation backend to accomplish this.
the other attack is on the certification authorities business process
... crook gets the issuing authority to give them a certificate with
all the same information ... but their public key; the key-owner may
have little control over the long term business process standards of
the issuing certification authority
This is one of the attacks on SSL domain name server certificates.
Supposedly the purpose for SSL domain name server certificates was
some perceived vulnerabilities in the domain name
infrastructure. Note, however, the authoritative agency(s) for domain
name ownership is the domain name infrastructure. The current process
has a SSL domain name server certificate applicant supplying some
amount of identification information. The certification authority then
has the error-prone and expensive job of contacting the domain name
infrastructure (authoritative agency for domain name ownership) and
comparing the supplied identification information (provided with the
certificate application) with what is on file at the domain name
infrastructure.
The attack isn't on the process that was used for the valid applicant
... the issue is that at any time in the future, can an attacker
compromise that process .... using any recognized, valid,
certification authority.
The side note is that the certification authority industry has
somewhat pushed a business process where the domain name supplies
their public key to the domain name infrastructure at the time they
register the domain name. Then when somebody applies for a SSL domain
name server certificate, they digitally sign the request. The
certification authority then just has to retrieve the on-file public
key from the domain name infrastructure and validate the digital
signature. This turns an expensive and error-prone identification
process into a much more reliable and less expensive authentication
process.
The catch-22 of course, is that if the certification authorities can
retrieve public keys from the domain name infrastructure for
authentication ... then just about anybody in the world could do the
same thing .... significantly reducing the need for any SSL domain
name server certificates.
misc past postings:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
https://www.garlic.com/~lynn/subpubkey.html#certless
SSL/TLS passive sniffing
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 05 Dec 2004 16:07:50 -0700
To: Anton Stiglic <astiglic@xxxxxxxx>
Cc: 'David Wagner' <daw@xxxxxxxx>, bnagy@xxxxxxxx,
cryptography@xxxxxxxx
Subject: Re: SSL/TLS passive sniffing
Anton Stiglic wrote:
I found allot of people mistakenly use the term certificate to mean
something like a pkcs12 file containing public key certificate and
private key. Maybe if comes from crypto software sales people that
oversimplify or don't really understand the technology. I don't know,
but it's a rant I have.
i just went off on possibly similar rant in comp.security.ssh
where a question was posed about "password or certficate"
https://www.garlic.com/~lynn/2004p.html#60
https://www.garlic.com/~lynn/2004q.html#0
Banks Test ID Device for Online Security
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 05 Jan 2005 23:46:32 -0700
Subject: Re: Banks Test ID Device for Online Security
To: Bill Stewart <bill.stewart@xxxxxxxx>
CC: R.A. Hettinga <rah@xxxxxxxx>, cryptography@xxxxxxxx
Bill Stewart wrote:
Yup. It's the little keychain frob that gives you a string of
numbers, updated every 30 seconds or so, which stays roughly in sync
with a server, so you can use them as one-time passwords instead of
storing a password that's good for a long term.
So if the phisher cons you into handing over your information,
they've got to rip you off in nearly-real-time with a MITM game
instead of getting a password they can reuse, sell, etc.
That's still a serious risk for a bank, since the scammer can use it
to log in to the web site and then do a bunch of transactions
quickly; it's less vulnerable if the bank insists on a new SecurID
hit for every dangerous transaction, but that's too annoying for most
customers.
in general, it is something you have authentication as opposed to
the common shared-secret something you know authentication.
while a window of vulnerability does exist (supposedly something that
prooves you are in possession of something you have), it is orders
of magnitude smaller than the shared-secret something you know
authentication.
there are two scenarios for shared-secret something you know
authentication
- a single shared-secret used across all security domains ... a
compromise of the shared-secret has a very wide window of
vulnerability plus a potentially very large scope of vulnerability
- a unique shaerd-secret for each security domain ... which helps
limit the scope of a shared-secret compromise. this potentially worked
with one or two security domains ... but with the proliferation of the
electronic world ... it is possible to have scores of security
domains, resulting in scores of unique shared-secrets. scores of
unique shared-secrets typically results exceeded human memory capacity
with the result that all shared-secrets are recorded someplace; which
in turn becomes a new exploit/vulnerability point.
various financial shared-secret exploits are attactive because with
modest effort it may be possible to harvest tens of thousands of
shared-secrets.
In one-at-a-time, real-time social engineering, may take compareable
effort ... but only yields a single piece of authentication material
with a very narrow time-window and the fraud ROI might be several
orders of magnitude less. It may appear to still be large risk to
individuals ... but for a financial institution, it may be relatively
small risk to cover the situation ... compared to criminal being able
to compromise 50,000 accounts with compareable effort.
In some presentation there was the comment made that the only thing
that they really needed to do is make it more attactive for the
criminals to attack somebody else.
,br>
It would be preferabale to have a something you have authentication
resulting in a unique value ... every time the device was used. Then
no amount of social engineering could result in getting the victim to
give up information that results in compromise. However, even with
relatively narrow window of vulnerability ... it still could reduce
risk/fraud to financial institutions by several orders of magnitude
(compared to existing prevalent shared-secret something you know
authentication paradigms).
old standby posting about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
Banks Test ID Device for Online Security
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 06 Jan 2005 06:52:30 -0700
Subject: Re: Banks Test ID Device for Online Security
To: Bill Stewart <bill.stewart@xxxxxxxx>
CC: R.A. Hettinga <rah@xxxxxxxx>, cryptography@xxxxxxxx
oh, and this is old discussion of a unit that has been in use in
europe ... it basically is very inexpensive calculator with 7816
contacts that you can slip a smartcard into. it is used in a
challenge/response scenario, a numeric keypad is used to enter the
challenge, which is passed to the smartcard, which does something and
the response is displayed. the person enters the displayed response.
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
works with anything that can present a challenge and has a numeric
keypad for the response (even works over telephone with VRU).
note that in any online scenario ... the server-side can do security
proportional to risk by making a decision to ask or not ask for
additional inputs. possible scenario is bill pay in home banking, use
authentication for initial access and then if total transactions
exceed some value ... ask for additional authentication input (trading
off convenience and risk, in online scenario it doesn't need to be all
just one way or another way, there is some amount of latitude for
adaptive implementation).
Note that the additional authentication input can also be used for
interpreting the (human specific) input as evidence of approval for
the transaction(s) as opposed to simply authentication.
other pieces of the previous mentioned thread on security proportional
to risk:
https://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
https://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#62 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#64 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#68 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#70 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#75 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#10 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#35 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
Dell to Add Security Chip to PCs
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dell to Add Security Chip to PCs
Date: Fri, 04 Feb 2005 11:07:32 -0700
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: camera_lumina@xxxxxxxx,
cryptography@xxxxxxxx,
rah@xxxxxxxx
Peter Gutmann wrote:
Neither. Currently they've typically been smart-card cores glued to the
MB and accessed via I2C/SMB.
and chips that typically have had eal4+ or eal5+ evaluations. hot topic
in 2000, 2001 ... at the intel developer's forums and rsa conferences
Dell to Add Security Chip to PCs
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dell to Add Security Chip to PCs
Date: Fri, 04 Feb 2005 11:12:59 -0700
To: Erwann ABALEA <erwann@xxxxxxxx>
CC: Trei, Peter <ptrei@xxxxxxxx>,
Tyler Durden <camera_lumina@xxxxxxxx>,
rah@xxxxxxxx, cryptography@xxxxxxxx
Erwann ABALEA wrote:
I've read your objections. Maybe I wasn't clear. What's wrong in
installing a cryptographic device by default on PC motherboards? I
work for a PKI 'vendor', and for me, software private keys is a
nonsense. How will you convice "Mr Smith" (or Mme Michu) to buy an
expensive CC EAL4+ evaluated token, install the drivers, and solve
the inevitable conflicts that will occur, simply to store his
private key? You first have to be good to convice him to justify the
extra depense. If a standard secure hardware cryptographic device
is installed by default on PCs, it's OK! You could obviously say
that Mr Smith won't be able to move his certificates from machine A
to machine B, but more than 98% of the time, Mr Smith doesn't need
to do that. Installing a TCPA chip is not a bad idea. It is as
'trustable' as any other cryptographic device, internal or
external. What is bad is accepting to buy a software that you won't
be able to use if you decide to claim your ownership... Palladium is
bad, TCPA is not bad. Don't confuse the two.
the cost of EAL evaluation typically has already been amortized across
large number of chips in the smartcard market. the manufacturing costs
of such a chip is pretty proportional to the chip size ... and the
thing that drives chip size tends to be the amount of eeprom memory.
in tcpa track at intel developer's forum a couple years ago ... i gave
a talk and claimed that i had designed and significantly cost reduced
such a chip by throwing out all features that weren't absolutely
necessary for security. I also mentioned that two years after i had
finished such a design ... that tcpa was starting to converge to
something similar. the head of tcpa in the audience quiped that i
didn't have a committee of 200 helping me with the design.
one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: cryptography@xxxxxxxx
Subject: one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
Date: Tue, 08 Feb 2005 07:38:10 -0700
Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/02-08-2005/0002986646&EDATE=
According to a recent study jointly released by Vontu Inc., the leader
in Data Loss Prevention solutions, and the Ponemon Institute, a research
institute dedicated to privacy management practices in business and
government, the most likely threat to information security is not the
typical hacker, virus or worm, but rather the malicious or careless
corporate insider.
... snip ...
link-layer encryptors for Ethernet?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: link-layer encryptors for Ethernet?
Date: Wed, 09 Feb 2005 09:27:26 -0700
To: Joseph Tardo <tardo@xxxxxxx>
CC: Steven M. Bellovin <smb@xxxxxx>, cryptography@xxxxxxx
Joseph Tardo wrote:
DEC used to make one (the DESNC), I don't remember the Xerox product.
Cylink used to make one, and may even still (as Safe-Net).
FWIW, IEEE has working group 802.1ae doing Ethernet MAC layer
encryption. But then, they had 802.10 (only implementation I know of was
the DESNC) for many years before retiring it.
The market for these kinds of devices has been notoriously small. May I
ask what your use case is?
the internal network was larger than the arpanet/internet just about
the whole time up until about mid-85. all the links leaving physical
premises had to be encrypted ... there was the claim that over half of
all link encryptors in the world were on the internal network (and put at
least one of the major products/companies into business). lots of
random comments about the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
small sample posting about the internal net passing 1000 nodes not
long after internet passed 255 nodes.
https://www.garlic.com/~lynn/internet.htm#22
one of the big issues in part of this period was getting link encryptors on
links that cross national boundaries.
link-layer encryptors for Ethernet?
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: link-layer encryptors for Ethernet?
Date: Wed, 09 Feb 2005 10:26:57 -0700
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Joseph Tardo <tardo@xxxxxxxx>, cryptography@xxxxxxxx
Steven M. Bellovin wrote:
Yup. Often, large corporations had policies requiring them, because of
how frequently a transoceanic fiber would be cut and the circuits
rerouted to satellite.
how 'bout microwave terrestrial ... remember all the press about the
consulate in san fran that supposedly had clear shot at the mci
microwave antenna complex?
san jose south valley complex had T3 collins digital radio between the
main plant site (roof of bldg. 12) and stl/bldg.90. i've heard
comments from people driving the stretch of 87 having their radar
detectors go off when they are in the straight line between bldg. 12
and the repeating tower on top of the hill going to bldg.90.
a similar setup went to the lsg/bldg.29 (los gatos lab) ... with a
repeating tower on the hill above san jose dump.
my hsdt project had some of the circuits
https://www.garlic.com/~lynn/subnetwork.html#hsdt
and also put in a tdma system that ran off a transponder on sbs4. had
4.5meter dish in the back parking lot of bldg.29 with tail circuits to
the main plant site, a 4.5meter dish out behind yorktown research, and
a 7meter dish on the austin plant site.
i got tired of paying all the money for the link encryptors ... and
got involved in designing a board that was a lot more powerful and
orders of magnitude cheaper ... which caused some churn.
A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Amir Herzberg <herzbea@xxxxxxxx>,
Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
Date: Thu, 10 Feb 2005 19:03:37 -0700
Steven M. Bellovin wrote:
"Unusual CA"? I'm not sure what a *usual* CA is.
Just for fun, I opened up the CA list that came with my copy of
Firefox. There are no fewer than 40 different entities listed, many
of whom have more than one certificate. I personally know less than
half of them to be trustworthy -- and that's assuming that, say,
Thawte, Thawte Consulting, and Thawte Consulting cc are all the same
company and I can count that as three different ones. I had no idea
that the U.S. Postal Service had a CA that was trusted by my
browser -- and I dare say that many non-Americans wouldn't trust it at
all, on the assumption that it would do whatever the U.S. government
told it to do.
cylink had the contract ... bea had subcontract. usps was going to do
some sort of in-person verification before issuing the certificate ...
along the lines of US passports.
https://web.archive.org/web/20050212211937/http://www.gcn.com/17_24/news/33918-1.html
this dates back to the days when the CA industry was floating business
cases that there was going to be $100/annum x.509 identity certificate
for every person in the country (the $20b/annum gift to the CA
industry story).
there was some rumor that if the gov. wouldn't cough up the
$20b/annum, then the financial industry was just chopping at the bit
to turn over $20b/annum to certification authorities. there is a story
from the period about an offer to a financial institution that if they
would transmit a copy of the master account database of tens of
millions of customers to the certification authority ... the
certification authority would re-arrange the bits in each database
entry into this magic format called a certificate and return the
re-arranged magic bits to the financial institution at a mere
$100/database entry (nominally overnight ... but possibly actually
several days, maybe only earning the CA a measely $1b/day of work).
this overlapped with the realization that identity certificates were
composed at some point in the past w/o any knowledge of just what
identity information any future relying parties might require .... as
a result there was one strategy that it would be necessary to overload
all identity certificate with every possibly piece of identity
information so as to cover all possible requirements possibly needed
by future unknown relying parties.
at the same time, the financial industry was realizing that identity
certificates represented huge privacy and liability exposures ... and
so you started to see retrenching by various parties (particularly the
financial industry) to relying-party-only certificates. misc. past
posts about relying-party-only certificates:
https://www.garlic.com/~lynn/subpubkey.html#rpo
The problem lurking in the background is that fundamentally, the
certificate design-point is an offline paradigm in a situation where
the relying-party has absolutely no recourse for obtaining information
about the origin of the digital signature (so is reduced to operating
with a letter-of-credit paradigm from the sailing ship era).
This fact was well highlighted in digitally signed payment scenario. A
bank customer was issued a relying-party-only certificate by their
financial institution (after registering their public key in the
financial institution's account record). The customer would then
create a payment authorization message, digitally sign the message and
then transmit the message, the digital signature and the bank's
relying-party-only certificate back to the bank. Since the bank
already has the customer's public key on file, the first thing it does
is discard the transmitted certificate and verifies the digital
signature with the on-file public key.
Another minor annoyance was that typical digital certificate was
nominally two orders of magnitude (one hundred times) larger than the
typical 8583 payment message. So not only were the relying-party-only
certificates redundant and superfluous ... its only apparent purpose
was to increase transmission payload bloat by a factor of 100 times.
some past posts about browser trusted public key lists:
https://www.garlic.com/~lynn/aepay4.htm#comcert14 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates
https://www.garlic.com/~lynn/2003l.html#27 RSA vs AES
ATM machine security
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: ATM machine security
Date: Tue, 22 Feb 2005 10:00:35 -0700
To: Lee Parkes <leep@xxxxxxxx>
CC: cryptography@xxxxxxxx
Lee Parkes wrote:
Hi,
I'm working on a project that requires a benchmark against which to
judge various suppliers. The closest that has similar requirements
is the ATM industry. To this end I'm looking for any papers,
specifications or published attacks against ATM machines and their
infrastructure. I'm also looking for what type of networks they use
and the crypto they use to protect comms. Also any standards would
be good that the ATM industry has to adhere to.
messages/networks tend to be some flavor of iso8583 (used for both
credit and debit). most associations have requirement for DUKPT
(derived unique key per transaction) DES and transition to 3DES.
do search engine some flavor of 8583, dukpt, and/or x9 (x9 is the
us/ansi financial standards organization ... they have some
recognition at places like NIST where they've gotten around to saying
that they no longer have to rewrite X9 crypto standards for FIPS
... but can directly reference the X9 documents).
lots of the attacks aren't directly on the ATM machines ... but on the
cards used at ATM machines ... aka skimming attacks. there is the
stuff about overlays on the front of ATM machines to capture
information as the card passes thru for valid transations. the
captured information is then used to manufactur counterfeit cards (i
think there was even a scene on this on one of last seasons CSI tv
shows).
MD5 collision in X509 certificates
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: MD5 collision in X509 certificates
Date: Sat, 05 Mar 2005 09:23:11 -0700
To: Victor Duchovni <Victor.Duchovni@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Victor Duchovni wrote:
What is the significance of this? It seems I can get a certificate for
two public keys (chosen, not given) while only proving posession of the
first. Is there anything else? In what sense is the second public key
useful to the attacker?
the purpose of a certificate is analogous to the old letters of credit
in the sailing ship days .... it supposedly establishes the bonifides
of the individual in an offline, non-connected world where the relying
party has no other recourse regarding trust/integrity of the
individual that they are dealing with.
in the PKI/certificate world ... the relying party receives some sort
of digitally encrypted/signed information and validates it using the
public key presented in the attached certificate. a correctly
validation then implies some kind of 3-factor authentication (although
the PKI/certificate paradigm tends to totally gloss over this
characteristic, instead attempting to focus the communities attention
on the value of the certification as opposed to focusing the attention
on any possibility/value/trust that some part of 3-factor
authentication might have occured).
In any case, if the public key (from some source, possibly a
certificate) is able to validate the transmission, then the relying
party assumes that some portion of 3-factor authentication occured in
the access and use of the corresponding private key ... possibly
https://www.garlic.com/~lynn/subintegrity.html#3factor
- something you have (private key exclusively in a hardware token)
- something you know (hardware token won't work appropriately w/o PIN)
- something you are (hardware token requires some biometric)
in any case, given that the relying party accepts the validation by
the public key as representing some implied 3-factor authentication
involved in access and use of the corresponding private key ... then
the relying party may be faced with just who the implied
authentication corresponds to. In the typical, long time accepted
business process ... the relying party will have prior relationship
with the entity being authenticated and it will be explicit and/or
implicit in the communication itself. In the more modern world, in the
situations where the relying party has no prior relationship with the
authenticated entity ... they will have access to online and/or
real-time information to establish that fact.
However, certificates were targeted at the offline email world
... where the email was created, digitally signed (presumably after
some form of 3-factor authentication occuring to establish access/use
of the private key), and the email, digital signature, and certificate
packaged up and sent off to some party that there had been no previous
communciation (might be considered spam in this day and age). After
some number of intermediary store-and-forwards stops, the package
arrives at the post office of the relying party. the relying party
eventually calls their post office, exchanges emails and hangs up.
At this point the relying party is presented with a digital signed
message with whom that they had no prior communciation. The attached
certificate provides the public key for validating the digital
signature and the rest of the certificate contents is supposedly to
attest to some characteristic of the email sending party (that the
relying party has no other way of validating).
The implication is that if i can substitute a public key in some
certificate that attests to represent some other party .... then it
may be some form of identity theft (fraudulent messages can be created
that otherwise appear to have originated from you ... and validate
with the substituted public key). The other might be elevation of
privileges .... adding characteristics to a certificate that were
otherwise not provided.
MD5 collision in X509 certificates
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: MD5 collision in X509 certificates
Date: Sat, 05 Mar 2005 11:13:40 -0700
To: Victor Duchovni <Victor.Duchovni@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Victor Duchovni wrote:
What is the significance of this? It seems I can get a certificate for
two public keys (chosen, not given) while only proving posession of the
first. Is there anything else? In what sense is the second public key
useful to the attacker?
so three kinds of attacks on certificate contents ... the previously two
mentioned
- identity theft
- privilege escalation
the other is possibly by the relying party against the key owner.
in the early '90s identity certificates were all the rage. some
problems were at the time the certification took place ... it might
not be possible for the certification authority to determine all
possible kinds of identity information that a relying party (at any
point in the future) might require ... so there was a trend to
overloading an identity certificate with all possible types of
identity information on the off chance that something might be useful
to some relying party in the future. this led to increasing
realization that such collection of identity information might
represent various kinds of privacy violation and you saw some
retrenching to relying-party-only certificates in the mid-90s
... misc. relying-party-only certificates only containing an account
number to be used in online/real-time transaction (note however, in
online/real-time relying-party-only scenario it is also trivial to
show that certificates are redundant and superfluous)
https://www.garlic.com/~lynn/subpubkey.html#rpo
the other thing in the 90s was trying to project a value proposition
for certificates. there was a lot of FUD and confusion generated about
the value of certificates to the point that it was frequently obscured
that it was even necessary to have security and safety around the
protection and use of the private key ... and/or that any form of
3-factor authentication was even involved in the access and use of the
private key. To this day, you have people writing about using a
digital certificate to create a digital signature.
So another value representation for digital certificates was that of
non-repudiation. basically if the non-repudiation flag in a digital
certificate was checked/marked ... then the relying party could assume
non-repudiation on the part of the originating party. Again this is a
scenario trying to represent the value of a digital certificate in
place of the safety and security around the access and use of the
private key.
So the story given to merchants in the merchant/consumer market place
.... was that the existing circumstances were that in any dispute the
burden of proof is on the merchant .... but the proposal was that if a
merchant could produce any certificate (for the consumer/originator
public key) that had the non-repudiation flag marked/checked,
then the burden of proof (in a dispute) would shift from the merchant
to the consumer.
So if that effort had been successful ... then it would be in the
interest of merchants to be able to produce a consumer digital
certificate that included the non-repudiation flag (regardless of
whether that certificate had been used in the original transaction or
not .... since by definition all burden of proof then is shifted to the
consumer).
some of this is discussed in various postings regarding finread ...
where the EU attempted to dictate some minimum hardware environment that
would provide some level of assurance around the access and use of the
private key (which helps diffuse the confusion around whether the
digital signature value proposition relies solely in the existance of a
digital certificate .... or whether there is some value in controlling
the access and use of private keys .... and it possibly isn't the case
that digital signatures are generated by digital certificates):
https://www.garlic.com/~lynn/subintegrity.html#finread
other past postings on 3-factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor
two-factor authentication problems
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: two-factor authentication problems
Date: Mon, 07 Mar 2005 15:36:23 -0700
To: gabriel@castelain.com.au
CC: 'Matt Crawford' <crawdad@fnal.gov>, 'Ed Gerck' <egerck@nma.com>,
cryptography@metzdowd.com
Gabriel Haythornthwaite wrote:
You're quite correct Matt,
Which is why IMHO you can only really get true non-repudiation through use
of PKI. And more specifically:
- where the key pair was generated by the end-user, and
- where the server has stored a copy of the transaction - digitally signed
by the end user - which it can reproduce in court.
In this case, a corrupt operator could not have faked the transaction even
if they had wanted to.
RSA SecureID and OATH technology have some great virtues:
- they cost nothing to integrate at the client end - there is no client
"footprint" so there's nothing to go wrong
- they are relatively easy to understand and use
- they're unquestionably better than reliance on user IDs and passwords.
What they won't do is:
- provide non-repudiation
- defend against man-in-the-middle attacks, or
- provide a robust defence against phishing scams
And for these reasons I suspect their days are numbered.
in general, non-repudiation is a legal term and is associated with a
legal signature ... which implies a person has read, understood,
agrees, approves, and/or authorizes what is being signed.
a digital signature is somewhat of a semantic misnomer since by itself,
it carries none of the characteristics commonly associated with a legal
signature.
a digital signature, by itself, implies that some entity has accessed
and used a specific private key. there is nothing in the standard, basic
PKI infrastructure that either
- implies that anything associated with any form of 3-factor
authentication was necessary in the access and use of a private key (in
the generation of a digital signature)
- that there was any demonstration that there was any reading,
understanding, agreement, approval, and/or authorization associated with
the access and/or use of a private key (in the generation of a digital
signature).
part of this i pointed out in a number of postings on dual-use digital
signature attack ... where the scenario is that digital signature is
being used to imply simple authentication aka possibly some flavor of a
challenge was transmitted, the receiving entity then used a private key
to digitally sign the challenge and return the digital signature (there
is a extremely vague implicit assumption that any component of 3factor
authentication was used in access and use of the private key ... with
the existance of a digital signature hopefully implying that some
component of 3factor authentication actually occured in the access and
use of the private key).
issues are
- frequently challenge type protocols don't bother to present (the
possibly totally random) bits (being signed) to the entity (that is
assumed to be associated with the digital signature).
- frequently infrastructures that attempt to equate legal signature and
digital signature ... will accept the existance of a digital signature
applied to some number of bits as representing that the associated
entity actually read, understood, agrees, approves, and/or authorizes
the semantic meaning associated with the bits that were signed ... w/o
requiring either a) some demonstration/proof that 3factor authentication
was used in the access and use of the private key for the digital
signature and/or b) that the meaning of what was digital signed had
actually been read, understood, agrees, approves, and/or authorizes
in the dual-use attack, bits that might have semantic meaning are
presented as random and/or meaningless as part of an authentication
challenge/response protoocol. The attacker then takes and represents
that the challenge bits that were signed ... were actually signed in the
sense of a legal signature.
as a totally extraneous observation ... the discussion up to this point
has been totally agnostic with regard to whether an infrastructure
attempting to show some relationship between a digital signature and a
legal signature involves PKI in anyway what so ever and/or is totally
certificate-less with regard to establishing a relationship between an
entity and what might be assumed from the existance of a digital signature.
past posts regarding 3-factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor
EU finread standard attempting to address some of the issues regarding
providing some level of assurance about 1) any characteristic of 3factor
authentication actually occuring when the private key was accessed and
used for a digital signature and 2) the entity might have actually read
and approves the transaction
https://www.garlic.com/~lynn/subintegrity.html#finread
past posts on dual-use vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
https://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#35 Credit card leaks continue at a furious pace
https://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004m.html#4 REVIEW: "Biometrics for Network Security", Paul Reid
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns
past posts on non-repudiation ... and possibly some characteristics that
might be required to demonstrate a person has read, understood,
agrees, approves, and/or authorizes what was digitally signed:
https://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on
https://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aepay11.htm#22 FBI Probing Theft of 8 Million Credit Card Numbers
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
https://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#ocrp Online Certificate Revocation Protocol
https://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
https://www.garlic.com/~lynn/aadsm6.htm#nonreput Sender and receiver non-repudiation
https://www.garlic.com/~lynn/aadsm6.htm#nonreput2 Sender and receiver non-repudiation
https://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror10 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
https://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
https://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki9 Software for PKI
https://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
https://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm10.htm#cfppki13 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
https://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
https://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
https://www.garlic.com/~lynn/aadsm10.htm#bio7 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
https://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign
https://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses "Authority-stamp-signatures"
https://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
https://www.garlic.com/~lynn/aadsm14.htm#20 Payments as an answer to spam (addenda)
https://www.garlic.com/~lynn/aadsm14.htm#23 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
https://www.garlic.com/~lynn/aadsm14.htm#48 basic question: semantics of "map", "tie", etc in PKI
https://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
https://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#37 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#40 FAQ: e-Signatures and Payments
https://www.garlic.com/~lynn/aadsm16.htm#9 example: secure computing kernel needed
https://www.garlic.com/~lynn/aadsm16.htm#11 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
https://www.garlic.com/~lynn/aadsm16.htm#14 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm16.htm#17 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm16.htm#18 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm16.htm#23 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#28 Definitions of "Security"?
https://www.garlic.com/~lynn/aadsm17.htm#53 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#55 MD5 collision in X509 certificates
https://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week
https://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
https://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
https://www.garlic.com/~lynn/2001g.html#1 distributed authentication
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
https://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
https://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
https://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
https://www.garlic.com/~lynn/2002d.html#16 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002d.html#41 Why?
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#29 Crazy idea: has it been done?
https://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
https://www.garlic.com/~lynn/2002e.html#58 O'Reilly C Book
https://www.garlic.com/~lynn/2002f.html#10 Least folklorish period in computing (was Re: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002f.html#23 Computers in Science Fiction
https://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
https://www.garlic.com/~lynn/2002f.html#45 Biometric Encryption: the solution for network intruders?
https://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
https://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002j.html#24 Definition of Non-Repudiation ?
https://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
https://www.garlic.com/~lynn/2002k.html#42 MVS 3.8J and NJE via CTC
https://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
https://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
https://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#36 (OT) acceptance of technology, was: Convenient and secure
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
https://www.garlic.com/~lynn/2002p.html#23 Cost of computing in 1958?
https://www.garlic.com/~lynn/2003e.html#47 Public key and the authority problem
https://www.garlic.com/~lynn/2003f.html#35 Public Encryption Key
https://www.garlic.com/~lynn/2003f.html#37 unix
https://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003h.html#18 Authentication protocol
https://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature
https://www.garlic.com/~lynn/2003h.html#38 entity authentication with non-repudiation
https://www.garlic.com/~lynn/2003h.html#42 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs
https://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
https://www.garlic.com/~lynn/2003.html#29 Message (authentication/integrity); was: Re: CRC-32 collision
https://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
https://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
https://www.garlic.com/~lynn/2003k.html#6 Security models
https://www.garlic.com/~lynn/2003l.html#65 Strength of RSA with known plain-text
https://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the same key for authentication and encryption
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003o.html#22 securID weakness
https://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
https://www.garlic.com/~lynn/2003o.html#44 Biometrics
https://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
https://www.garlic.com/~lynn/2003p.html#11 Order of Encryption and Authentication
https://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
https://www.garlic.com/~lynn/2004e.html#20 Soft signatures
https://www.garlic.com/~lynn/2004h.html#13 Two-factor Authentication Options?
https://www.garlic.com/~lynn/2004h.html#30 ECC Encryption
https://www.garlic.com/~lynn/2004.html#29 passwords
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004m.html#4 REVIEW: "Biometrics for Network Security", Paul Reid
https://www.garlic.com/~lynn/2005d.html#32 Is a cryptographic monoculture hurting us all?
AADS Postings and Posting Index,
next, previous
- home