Re: [Cryptography] encoding formats should not be committee'ized

2013-10-02 Thread Anne Lynn Wheeler

On 09/30/13 04:41, ianG wrote:

Experience suggests that asking a standards committee to do the encoding format 
is a disaster.

I just looked at my code, which does something we call Wire, and it's 700 loc.  
Testing code is about a kloc I suppose.  Writing reference implementations is a 
piece of cake.

Why can't we just designate some big player to do it, and follow suit? Why 
argue in committee?



early 90s annual ACM SIGMODS (DBMS) conference in San Jose ... general meeting 
in (full) ballroom ... somebody in the audience asks panel on the stage what is 
all this x.5xx stuff about ... and one of the panelists replies that it is a 
bunch of networking engineers trying to re-invent 1960s DBMS technology.

CA industry is pitching $20B/annum business case on wallstreet ... where the 
financial industry pays CAs $100/annum for every account for a 
relying-party-only digital certificate ... where the financial industry 
providing all the information that goes into the certificate (CA industry just 
reformats all the information and digitally signs it). In one case of 
institution with 14M accounts, the board asks what is this $1.4B/annum thing 
about?

I repeatedly point out that it is redundant and superfluous since the 
institution already has all the information. Purpose of the certificate is to 
append to every financial transaction. I also point out that digital 
certificate payload is enormous bloat, 100 times larger than the transaction 
size its attached to (besides redundant and superfluous)

CA industry then sponsors x9.63 work in X9 financial standards industry for 
compressed certificate format ... possibly getting the payload bloat down to 
10 times (instead of hundred times). Part of the compressed certificate work was to 
eliminate fields that the relying party already had. Since I had already shown that the 
relying party (institution) already had all fields, it was possible to compress every 
certificate to zero bytes ... so rather than doing digitally signed transactions w/o 
certificates ... it was possible to do digitally signed transactions with mandated 
appended zero-byte certificates.

Trivia: last few years before he passed, Postel would let me do part of STD1. 
There was a joke that while IETF required at least two interoperable 
implementations before standards progression, ISO didn't even require that a 
standard be implementable.

--
virtualization experience starting Jan1968, online at home since Mar1970
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Gilmore response to NSA mathematician's make rules for NSA appeal

2013-09-25 Thread Anne Lynn Wheeler

We had been asked to come in and help wordsmith the cal. state digital signature act. Several of 
the parties were involved in privacy issues and also working on Cal. data breach notification act 
and Cal. opt-in personal information sharing act. The parties had done extensive public surveys on 
privacy and the #1 issue was identity theft, namely the form of account fraud as result 
of data breaches. There was little or nothing being done about this so there was some hope that the 
publicity from the breach notifications would motivate corrective action. The issue is that 
normally an entity takes security and countermeasures in self-protection ... the entities suffering 
the data breaches weren't at risk ... it is the account holders. Since then several Federal breach 
notification bills have been introduced about evenly divided between having similar notification 
requirements and Federal preemption legislation eliminating requirement for 
notifications. The federal bills elimina
ting noti
fications cite industry specifications call for account encryption (that were 
formulated after the cal. legislation). We've periodically commented in the 
current paradigm, even if the planet was buried under miles of information 
hiding encryption it still wouldn't stop information leakage. One problem, is 
account information is basically used for authentication and as such needs to 
be kept completely confidential and never divulged. However, at the same time, 
account information is also required in dozens of business processes at 
millions of location around the world.

The cal.personal information opt-in sharing legislation would require institution have record from the 
individual authorizing sharing of information. However, before the cal legislation passed, an opt-out 
(federal preemption) provision was added to GLBA. GLBA is now better known for the repeal of Glass-Steagall. At the 
time, the rhetoric in congress was the primary purpose of GLBA was if you already had bank charter you got to keep it, 
however, if you didn't have a charter, you wouldn't be able to get one (i.e. eliminate new parties from coming in and 
competing with banks). However, GLBA was loaded up with other features like repeal of Glass-Steagall and the 
opt-out personal information sharing (i.e. the financial institution needed record of person declining 
sharing of personal information ... rather than opt-in which required institution to have record 
authorizing sharing).

A few years ago, I was at a national annual privacy conference in Wash DC. (hotel just up the 
street from spy museum). There was a panel discussion with the FTC commissioners. Somebody in the 
audience asked the FTC commissioners if they were going to do anything about GLBA 
opt-out privacy sharing. He said he worked on callcenter technology used by all the 
major financial institutions ... and that none of the 1-800 opt-out desks had 
provisions for recording information from the call (aka an institution would *NEVER* have a record 
of a person objecting to sharing their personal information). The FTC commissioners just ignored 
him.

--
virtualization experience starting Jan1968, online at home since Mar1970
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-08 Thread Anne Lynn Wheeler

note when the router hughes references was 1st introduced in in IETF gateway 
committee meeting as VPN it caused lots of turmoil in the IPSEC camp as well as 
with the other router vendors. The other router vendors went into standards 
stall mode ... their problem was none of them had a product with processors 
capable of handling the crypto processing. A month after the IETF meeting one 
of the vendors announced what was supposedly an equivalent product ... but was 
actually their standard product (w/o crypto) packaged with hardware link 
encryptors (needed dedicated links instead of being able to tunnel thru the 
internet).

The IPSEC camp whined a lot but eventually settled for referring to it as 
lightweight IPSEC (possibly trying to imply it didn't have equivalent crypto).

As to DNSSEC ... the simple scenario is requiring domain owners to register a 
public key and then all future communication is digitally signed and 
authenticated with the onfile, registered public key (as a countermeasure to 
domain name take-over which affects the integrity of the domain name 
infrastructure and propogates to SSL CA vendors if they can't trust who the 
true owner is). Then the SSL CA vendors can also start requiring that SSL 
certificate requests also be digitally signed ... which can also be 
authenticated by retrieving the onfile public key (turning an expensive, 
error-prone and time-consuming identification process into a reliable and 
simple authentication process). The catch22 is once public keys can be 
retrieved in realtime ... others can start doing it also ... going a long way 
towards eliminating need for SSL certificates. Have an option piggy-back public 
key in the same response with the ip-address. Then do SSL-lite ... XTP had 
reliable communication minim
um 3-pack
et exchange ... compared to TCP requiring minimum 7-packet exchange.

In the key escrow meetings, I lobbied hard that divulging/sharing authentication keys was 
violation of fundamental security principles. Other parties at the key escrow meetings 
whined that people could cheat and use authentication keys for encryption. However, there 
was commercial no single point of failure business case for replicating keys 
used in encrypting data-at-rest corporate assets.

One might hypothesis that some of the current DNSSEC complexity is FUD ... 
unable to kill it ... make it as unusable as possible.

disclaimer: person responsible for original DNS worked at the science center in 
the early 70s when he was at MIT.

--
virtualization experience starting Jan1968, online at home since Mar1970
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread Anne Lynn Wheeler

On 09/07/13 05:19, ianG wrote:

If so, then the domain owner can deliver a public key with authenticity using 
the DNS.
This strikes a deathblow to the CA industry.  This threat is enough for CAs to 
spend a significant amount
of money slowing down its development [0].


unfortunately as far as SSL domain name certificate ... the domain name 
infrastructure is the
authoritative agency for domain name ownership ... the SSL domain name 
certification agencies
have to rely on the domain name infrastructure to validate true ownership for 
SSL domain name
applications. As I've repeatedly referenced ... this puts the CAs in catch22 
... they
need improved integrity of domain name infrastructure (attacks on ownership 
records of domain
name ownership and then being issued valid SSL certificate) ... which comes 
with lots of
DNSSEC ... but that also eliminates much of the need for SSL domain 
certificates.

as per prior reference about original working on SSL for electronic commerce 
... at least for
the financial industry I've repeatedly shown that digital certificates were 
redundant
and superfluous. I also shown that at the time, the addition of digital 
certificates
increased the payload size by two orders of magnitude (besides being redundant 
and superfluous).
That apparently motivated the compressed digital certificate financial 
standard effort ...
trying to reduce digital certificates so that the payload bloat was only ten 
times (instead
of hundred times) ... in large part by eliminating all information that the 
processing
institution already had. I demonstrated that processing institution would have 
all
information and therefor digital certificates could be reduced to zero bytes 
... so
instead of eliminating redundant and superfluous digital certificates ... it 
was possible
to mandate that zero byte certificates be appended to every transaction (it 
would be
possible to digitally sign a payment transaction for authentication ... and 
rely on
the individual's financial institution to have registered the person's public 
key ... w/o
having to increase the size of every payment transaction in the world by 100 
times just
to transmit a redundant and superfluous appended digital certificate).

I like the interchange at panel discussion in early 90s ACM SIGMOD ballroom 
open session,
somebody in the audience asked what was all this x.5xx stuff about and one of 
the panelists
said it was a bunch of networking engineers trying to reinvent 1960s database 
technology.

there was some amount of participation by the information assurance directorate 
in financial
industry standards meetings. at various times there were references to rifts 
between IA
and SIGINT ... but for all I know that may be kabuki theater. I was fairly 
vocal about
any backdoors could put financial industry at risk for bad guys discovering the 
vulnerabilities
... and wanted KISS applied to as much as possible (and backdoors forbidden)

there are other agendas in much of this. at the start of the century there
were several safe internet payment products pitched to major merchants 
(accounting for 70%
of internet transactions) which got high acceptance. Merchants have been 
indoctrinated for
decades that a large part of interchange fee is proportional to associated 
fraud rate ...
and the merchants were expecting an order of magnitude reduction in their fees 
(with
the safe products). Then came the cognitive dissonance when the banks told the 
merchants that
rather than major reduction in interchange fees with the safe payment 
products ... there would
effectively be a surcharge added to the highest fee that they were already 
paying (and all the
safe efforts collapse).

Part of the issue was that the bottom line for large issuing banks was 40%-60% 
from these
fees and an order of magnitude reduction in those fees would be a big hit to
their bottom line (the size of fees in part justified by fraud rates). The 
safe products
going a long way to eliminating most fraud and commoditizing the payment 
transaction
business ... which would also lower the bar for entry by competition.

--
virtualization experience starting Jan1968, online at home since Mar1970
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-06 Thread Anne Lynn Wheeler

we were brought in as consultants to a small client/server startup that wanted to do payment transactions on 
their server, they had this technology they called SSL they wanted to use, the result is now 
frequently called electronic commerce. The two people at the startup responsible for the 
commerce server we had worked with in prior life on parallel Oracle cluster scaleup.

As part of mapping SSL technology to payment transactions we had to audit operations 
selling SSL digital certificates and also came up with recommendations on how browsers 
and servers would deploy and use the technology. Almost immediately several of the recommendations 
were violated, resulting in some number of the exploits that continue to this day.

We were then tangentially involved in the Cal. data breach notification legislation, 
having been brought in to help wordsmith the Cal. electronic signature legislation. Many 
of the parties were heavily involved in privacy issues and had done numerous, indepth, 
public surveys. The number one issue was identity theft of the form involving 
fraudulent financial transactions ... frequently as result of data breach. The issue was 
nothing was being done about the problems and so it was hoped that the publicity from the 
notifications might motivate corrective action. Part of the issue is normally 
institutions take security measures in self-interests ... however, the institutions 
having breaches weren't at risk, it was the account holders.

PCI DSS shows up some time after Cal. data breach notification and frequently the joke is 
that if you have a breach ... you loose your PCI DSS certification. It turns out that 
there was a number of Federal data breach notification bills introduced, 
preempting state legislation and effectively eliminating notification requirements ... 
citing PCI DSS industry effort as justification for no longer needing notification.

Another problem we've frequently pointed out is current paradigm with dual 
use paradigm and even if the planet was covered in miles of information hiding 
encryption, it wouldn't stop data leakage. Account information is used for authenticating 
new transactions and so has a requirement that it be kept totally confidential and never 
divulged to anybody ... but at the same time, account information is needed in dozens of 
business processes at millions of locations around the planet.

disclaimer: we were co-authors of the x9.59 financial transaction standard that 
slightly tweaked the current payment paradigm and eliminated the dual-use 
characteristic  which then also eliminated the need to hide account 
information and as a result it also eliminated the need for SSL to hide account 
information in electronic commerce transactions  eliminating the major 
requirement for SSL in the world today.

--
virtualization experience starting Jan1968, online at home since Mar1970
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] NSA and cryptanalysis

2013-09-02 Thread Anne Lynn Wheeler

recent post with email discussing PGP-like implementation ... a decade before 
PGP in financial crypto blog
http://www.garlic.com/~lynn/2013i.html#69
and then a little later realizing there were 3-kinds of crypto (when I was told 
I could make as many boxes as I wanted ... but could only sell to a certain 
gov. agency).

In the late 90s, I worked on crypto chip for financial applications ... I would 
facetiously talk about taking a $500 mil-spec chip and cost reduce by 2-3 
orders of magnitude while making it more secure (final objective was well under 
a dollar). Part of the objective was also to eliminate all the vulnerabilities 
that payment chips being done primarily in Europe were prone too. Long winded 
thread in financial crypto blog
http://www.garlic.com/~lynn/subintegrity.html#yescard

About that time, I was also approached by the transit industry to make the 
payment chip meet transit turnstyle requirements (while not reducing any 
security) ... this was a contactless chip being able to do crypto operation in 
1/10th sec elapsed time and power profile of contactless transit turnstyle 
operation.

RSA chips at the time were really large implementing 1024-bit arithmatic requiring 
enormous power and contact operation to get time in a few seconds. It turns out I 
could have a AADS chip strawman with ECC that was higher integrity *AND* could meet 
the transit industry turnstyle contactless power  elapsed time profile. some 
past references to AADS chip strawman
http://www.garlic.com/~lynn/x959.html#aadsstraw

I was also asked to give presentation at Intel trusted computing ... gone 404 
but lives on at wayback machine
http://web.archive.org/web/20011109072807/http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp+s13

one of the problems in the early part of the century was that I wanted to go 
for higher than EAL4+ evaluation ... but NIST(somebody) pullled the ECC 
evaluation criteria ... and since ECC was part of the chip silicon ... w/o the 
ECC evaluation criteria ... I had to settle for EAL4+.

Possibly part of the issue with AADS chip strawman was I approached it as 
purely a cost issue ... and the objective was to eliminate all possible costs 
from the whole infrastructure ... the side effect of course, it also eliminated 
all related profit.

--
virtualization experience starting Jan1968, online at home since Mar1970
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)

2010-08-26 Thread Anne Lynn Wheeler

On 08/26/2010 06:38 AM, d...@geer.org wrote:

While I am *not* arguing that point, per se, if having a
better solution would require, or would have required, no
more investment than the accumulated profits in the sale
of SSL domain name certs, we could have solved this by now.


the profit from sale of SSL domain name certs had profit motivation pretty much
unrelated to the overall costs to the infrastructure ... and so there was
an extremely strong champion.

simply enhancing DNS and doing real-time trusted public key distribution
thru a trusted domain name infrastructure ... was all cost with no champion
with strong profit motivation.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: towards https everywhere and strict transport security

2010-08-26 Thread Anne Lynn Wheeler

On 08/25/2010 10:40 PM, James A. Donald wrote:

This is inherent in the layering approach - inherent in our current crypto 
architecture.


one of the things ran into the (ISO chartered) ANSI X3S3.3 (responsible for 
standards
related to OSI level3  level4) meetings with regard to standardization of HSP 
(high
speed protocol) ... was that ISO had policy that it wouldn't do standardization 
on
things that violated OSI model.

HSP violated OSI model by (and was turned down by X3S3.3)

1) went directly from level 4/5 interface to the MAC interface (bypassing
OSI level 3/4 interface)

2) supported internetworking ... which doesn't exist in OSI model ...
would set in non-existing layer between level3  level4

3) went directly to MAC interface ... which doesn't exist in OSI mdoel ...
something that sits approx. in the middle of layer3 (above link layer
and includes some amount of network layer).

In the IETF meetings at the time of original SSL/TLS ... my view was that
ipsec wasn't gaining tranction because it required replacing parts of
tcp/ip kernel stack (upgrading all the kernels in the world was much more
expensive then than it is now). That year two things side-stepped the
ipsec upfront kernel stack problem

* SSL ... which could be deployed as part of the application w/o
requiring changes to existing infrastructure

* VPN ... introduced in gateway sesssion at fall94 IETF meeting. This
was implemented in gateway routers w/o requiring any changes to existing
endpoints. My perception was that it upset the ipsec until they started
referring to VPN as lightweight ipsec (but that opened things for
ipsec to be called heavyweight ipsec). There was a problem with two
classes of router/gateway vendors ... those with processors that
could handle the crypto load and those that had processors that
could handle the crypto load. One of the vendors that couldn't
handle the crypto load went into standards stalling mode and also
a month after the IETF meeting announced a VPN product that
involved adding hardware link encryptors (which would then
required dedicated links between the two locations as opposed
to tunneling thru the internet.



I would contend that various reasons why we are where we are
... include solutions that have champions with profit motivation
as well as things like ease of introduction ... and issues with
being able to have incremental deployments with minimum disruption
to existing facilities (like browser application based solution
w/o requiring any changes to established DNS operation).

On the other hand ... when we were brought in to consult with
the small client/server startup that wanted to do payment
transactions (and had also invented SSL) ... I could mandate
multiple A-record support (basically alternative path mechanism)
for the webserver to payment gateway TCP/SSL connections. However,
it took another year to get their browser to support multiple-A
record (even when supplying them with example code from TAHOE
4.3 distribution) ... they started out telling me that multiple-A
record technique was too advanced.

An early example requirement was one of the first large
adopters/deployments for e-commerce server, advertized on national
sunday football and was expecting big e-commerce business during
sunday afternoon halftime. Their e-commerce webserver had
redundant links to two different ISPs ... however one
of the ISPs had habit of taking equipment down during the
day on sunday for maintenance (w/o multiple-A record support,
there was large probability that significant percentage of
browsers wouldn't be able to connect to the server on
some sunday halftime).

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)

2010-08-25 Thread Anne Lynn Wheeler

On 08/25/2010 09:04 AM, Richard Salz wrote:

Also, note that HSTS is presently specific to HTTP. One could imagine
expressing a more generic STS policy for an entire site


A really knowledgeable net-head told me the other day that the problem
with SSL/TLS is that it has too many round-trips.  In fact, the RTT costs
are now more prohibitive than the crypto costs.  I was quite surprised to
hear this; he was stunned to find it out.

Look at the tlsnextprotonec IETF draft, the Google involvement in SPDY,
and perhaps this message as a jumping-off point for both:
http://web.archiveorange.com/archive/v/c2Jaqz6aELyC8Ec4SrLY

I was happy to see that the interest is in piggy-backing, not in changing
SSL/TLS.



the work on HSP (high-speed protocol) in the late 80s was to do reliable 
transmission
in minimum 3-packet exchange; compared to 5-packet minimum for VMTP (rfc1045) 
and
7-packet minimum for tcp (disclaimer, i was on related technical advisory board
for HSP ... while at IBM ... over strong objections from the communication 
division;
but that also strong protested that we had come up with 3-tier architecture and 
were
out pitching it to customer executives ... at a time when they were attempting
to get the client/server genie back into the terminal emulation bottle)

then SSL theoretically being stateless on top of tcp added a whole bunch of
additional chatter. there has frequently between changing trade-offs between
transmission and processing ... but SSL started out being excessive in both
transmission and processing (in addition to having deployment requirement that
the user understand the relationship between the website they believed they
were talking to and the URL they had to supply to the browser  a requirement
that was almost immediately violated).

my pitch forever has been to leverage key distribution piggy-backed on
domain name to ip-address (dns) response ... and use that to do
encrypted/validated reliable transaction within HSP 3-packet minimum exchange.

as previously mentioned, somewhere back behind everything else ... there
is strong financial motivation in the sale of the SSL domain name digital
certificates.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Has there been a change in US banking regulations recently?

2010-08-14 Thread Anne Lynn Wheeler

On 08/13/2010 03:16 PM, Chris Palmer wrote:

When was this *ever* true? Seriously.


re:
http://www.garlic.com/~lynn/2010m.html#50

... original design/implementation. The very first commerce server 
implementation
by the small client/server startup (that had also invented SSL) ... was mall
paradigm, development underwritten by large telco (they were looking at being 
major
outsourcer of electronic commerce servers) ... then the individual store 
implementation
was developed.

we had previously worked with two people responsible for commerce server
(at small client/server startup) on ha/cmp ... they are mentioned in this
old posting about jan92 meeting in ellison's conference room
http://www.garlic.com/~lynn/95.html#13

they then left to join the small client/server startup ... and we also leave
what we had been doing. we then get brought in as consultants because they
want to do payment transactions on their server ... wanting to use this
technology called SSL that had been invented at the startup. We have to
go thru the steps of mapping the technology to payment business
processes ... including backend use involving the interaction between commerce
servers and the payment gateway; the payment gateway sitting on
the internet and interface to acquiring network backends ... misc. past
posts mentioning payment gateway
http://www.garlic.com/~lynn/subnetwork.html#gateway

we also have to do walkthru/audits of several of these new businesses calling
themselves Certification Authorities that were selling SSL domain
name digital certificates ... some past posts
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

approx. in the same era, but not exactly the same time (when webservers
were seeing the ssl cryptographic load  dropping back to only using it for
payment) ... some of the larger websites were starting to first see a plain
tcp/ip scaleup issue ... having  to do with tcp being originally designed
as session protocol ... and was effectively being misused by HTTP. As a
result most vendor implementations hadn't optimized session termination
... which was viewed as infrequent event (up until HTTP). There was six
month period or so ... that the large websites saw their processors
spending 90-95% of the cpu running the FINWAIT list (as part of session
termination).

The small client/server startup was also seeing (other) scaleup problems
in their server platforms used for downloading products (especially
browser product download activity) ... and in constant cycle of
adding servers. This was before  rotating front-ends ... so users were
asked to manually specify URL of specific server.

Their problem somewhat cleared up when they installed a large sequent
box ... both because of the raw power of the sequent server ... and
also because sequent claimed to have addressed the session terminal efficiency
sometime previously (related to commercial unix accounts with
20,000 concurrent telnet sessions).

For other topic drift ... I believe the first rotating, load-balancing
front-ends was with custom modified software for routers at google.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Has there been a change in US banking regulations recently?

2010-08-13 Thread Anne Lynn Wheeler

On 08/13/2010 02:12 PM, Jon Callas wrote:

What on earth happened?  Was there a change in banking regulations in the last
few months?


Possibly it's related to PCI DSS and other work that BITS has been doing. Also, 
if one major player cleans up their act and sings about how cool they are, then 
that can cause the ice to break.

Another possibility is that a number of people in financials have been able to 
get security funding despite the banking disasters because the risk managers 
know that the last thing they need is a security brouhaha while they are 
partially owned by government and thus voters.

I bet on synergies between both.

If I were a CSO at a bank, I might encourage a colleague to make a presentation 
about how their security cleanups position them to get an advantage at getting 
out from under the thumb of the feds over their competitors. Then I would make 
sure the finance guys got a leaked copy.

Jon


the original requirement for SSL deployment was that it was on from the 
original URL entered by the user. The drop-back to using SSL for only small 
subset ... was based on computational load caused by SSL cryptography  in 
the online merchant scenario, it cut thruput by 90-95%; alternative to handle 
the online merchant scenario for total user interaction would have required 
increasing the number of servers by factor of 10-20.

One possibility is that the institution has increased the server capacity ... 
and/or added specific hardware to handle the cryptographic load.

A lot of banking websites are not RYO (roll-your-own), internally developed ... 
but stuff they by from vendor and/or have the website wholly outsourced.

Also some number of large institutions have their websites outsourced to 
vendors with large replicated sites at multiple places in the world ... and 
users interaction gets redirected to the closest server farm. I've noticed this 
periodically when the server farm domain name and/or server farm SSL 
certificate bleeds thru ... because of some sort of configuration and/or 
operational problems (rather than seeing the institution SSL certificate that I 
thot I was talking to).

Another possibility is that the vendor product that they may be using for the 
website and/or the outsourcer that is being used ... has somehow been upgraded 
(software /or hardware).

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI, Part II

2010-08-06 Thread Anne Lynn Wheeler

Zeus malware used pilfered digital certificate
http://www.computerworld.com/s/article/9180259/Zeus_malware_used_pilfered_digital_certificate
Zeus Malware Used Pilfered Digital Certificate
http://www.pcworld.com/businesscenter/article/202720/zeus_malware_used_pilfered_digital_certificate.html



Zeus malware used pilfered digital certificate
http://www.networkworld.com/news/2010/080610-zeus-malware-used-pilfered-digital.html

from above:

The version of Zeus detected by Trend Micro had a digital certificate belonging
to Kaspersky's Zbot product, which is designed to remove Zeus. The certificate 
--
which is verified during a software installation to ensure a program is what it
purports to be -- was expired, however.

... snip ...

Certificate Snatching—ZeuS Copies Kaspersky’s Digital Signature
http://blog.trendmicro.com/certificate-snatching-zeus-copies-kasperskys-digital-signature/

...

there was another scenario of certificate-copying ( dual-use vulnerability)
discussed in this group a while ago. The PKI/certificate bloated payment
specification had floated the idea that that when payment was done with their
protocol, dispute burden-of-proof would be switched  placed on the consumer
(from the current situation where burden-of-proof is on the 
merchant/institution;
this would be a hit to REG-E ... and also apparently what has happened in the
UK with the hardware token point-of-sale deployment).

However, supposedly for this to be active, the payment transaction needed a 
consumer
appended digital certificate that indicated they were accepting dispute
burden-of-proof. The issue was whether the merchant could reference some
public repository and replace the digital certificate appended by the
consumer ... with some other digital certificate for the same public key
(possibly digital certificate actually obtained by the consumer for that
public key at some time in the past ... or an erroneous digital certificate
produced by a sloppy Certification Authority that didn't adequately perform
check for applicant's possession of the corresponding private key).

Of course, since the heavily bloated PKI/certificate payment specification,
performed all PKI-ops at the internet boundary ... and then passed
a normal payment transaction with just a flag claiming that PKI-checking
had passed ... they might not need to even go that far. There
was already stats on payment transactions coming thru with the flag
on ... and they could prove no corresponding PKI-checking had actually
occurred. With the burden-of-proof on consumer ... the merchant might
not even have to produce evidence that the appended digital certificates
had been switched.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI, Part II

2010-08-04 Thread Anne Lynn Wheeler

Kaspersky: Sham Certificates Pose Big Problem for Windows Security
http://www.ecommercetimes.com/story/70553.html

from above ..

Windows fails to clearly indicate when digital security certificates have been
tampered with, according to Kaspersky Lab's Roel Schouwenberg, and that
opens a door for malware makers.

... snip ...

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Five Theses on Security Protocols

2010-08-02 Thread Anne Lynn Wheeler

On 08/01/2010 01:51 PM, Jeffrey I. Schiller wrote:

I remember them well. Indeed these protocols, presumably you are
talking about Secure Electronic Transactions (SET), were a major
improvement over SSL, but adoption was killed by not only failing the
give the merchants a break on the fraud surcharge, but also requiring
the merchants to pick up the up-front cost of upgrading all of their
systems to use these new protocols. And there was the risk that it
would turn off consumers because it required the consumers setup
credentials ahead of time. So if a customer arrived at my SET
protected store-front, they might not be able to make a purchase if
they had not already setup their credentials. Many would just go to a
competitor that doesn't require SET rather then establish the
credentials.


SET specification predated these (as also internet specific, from the mid-90s, went on 
currently with x9a10 financial standards work ... which had requirement to preserve the 
integrity for *ALL* retail payments) ... the decade past efforts were later were much 
simpler and practical ... and tended to be various kinds of something you 
have authentication. I'm unaware of any publicity and/or knowledge about these 
payment products (from a decade ago) outside the payment industry and select high volume 
merchants.

The mid-90s, PKI/certificate-based specifications tended to hide behind a large 
amount of complexity ... and provide no effective additional benefit over  
above SSL (aka with all the additional complexity ... did little more than hide the 
transaction during transit on the internet).  They also would strip all the PKI 
gorp off at the Internet boundary (because of the 100 times payload size and 
processing bloat that the certificate processing represented) and send the 
transaction thru the payment network with just a flag indicating that certificate 
processing had occurred (end-to-end security was not feasible). Various past posts 
mentioning the 100 times payload size and processing bloat that certificates added 
to typical payment transactions
http://www.garlic.com/~lynn/subpubkey.html#bloat

In the time-frame of some of the pilots, there were then presentation by payment network 
business people at ISO standards meetings that they were seeing transactions come thru 
the network with the certificate processed flag on ... but could prove that 
no certificate processing actually occurred (there was financial motivation to lie since 
turning the flag on lowered the interchange fee).

The certificate processing overhead also further increased the merchant 
processing overhead ... in large part responsible for the low uptake ... even 
with some benefit of lowered interchange fee. The associations looked at 
providing additional incentive (somewhat similar to more recent point-of-sale, 
hardware token incentives in europe), effectively changing the burden of proof 
in dispute (rather than the merchant having to prove the consumer was at fault, 
the consumer would have to prove they weren't at fault; of course this would 
have met with some difficulty in the US with regard to regulation-E).

Old past thread interchange with members of that specification team regarding 
the specification was (effectively) never intended to do more than hide the 
transaction during transnmission:
http://www.garlic.com/~lynn/aepay7.htm#norep5 non-repudiation, was re: crypto 
flaw in secure mail standards

aka high-overhead and convoluted, complex processing of the specification 
provided little practical added benefit over and above what was already being 
provided by SSL.

oblique reference to that specification in recent post in this thread regarding 
having done both a PKI-operation benchmark (using BSAFE library) profile as 
well as business benefit profile of the specification (when it was initially 
published ... before any operational pilots):
http://www.garlic.com/~lynn/2010l.html#59 A mighty fortress is our PKI

with regard specifically to BSAFE processing bloat referenced in the above ... 
there is folklore that one of the people, working on the specification, 
admitted to a adding a huge number of additional PKI-operations (and message 
interchanges) to the specification ... effectively for no other reason than the 
added complexity and use of PKI-operations.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Five Theses on Security Protocols

2010-08-02 Thread Anne Lynn Wheeler

minor addenda about speeds  feeds concerning the example of mid-90s payment 
protocol specification that had enormous PKI/certificate bloat ... and SSL.

The original SSL security was predicated on the user understanding the 
relationship between the webserver they thought they were talking to, and the 
corresponding URL. They would enter that URL into the browser ... and the 
browser would then establish that the URL corresponded to the webserver being 
talked to (both parts were required in order to create an environment where the 
webserver you thot you were talking to, was, in fact, the webserver you were 
actually talking to). This requirement was almost immediately violated when 
merchant servers found that using SSL for the whole operation cost them 90-95% 
of their thruput. As a result, the merchants dropped back to just using SSL for 
the payment part and having a user click on a check-out/payment button. The 
(potentially unvalidated, counterfeit) webserver now provides the URL ... and 
SSL has been reduced to just validating that the URL corresponds to the 
webserver being talked to (or validating that the webserver being talke
d to, is the webserver that it claims to be; i.e. NOT validating that the 
webserver is the one you think you are talking to).

Now, the backend of the SSL payment process was SSL connection between the webserver and 
a payment gateway (sat on the internet and acted as gateway to the payment 
networks). Moderate to heavy load, avg. transaction elapsed time (at payment gateway, 
thru payment network) round-trip was under 1/3rd of second. Avg. roundtrip at merchant 
servers could be a little over 1/3rd of second (depending on internet connection between 
the webserver and the payment gateway).

I've referenced before doing BSAFE benchmarks for the PKI/certificate bloated 
payment specification ... and using a speeded up BSAFE library ... the people 
involved in the bloated payment specification claimed the benchmark numbers 
were 100 times too slow (apparently believing that standard BSAFE library at 
the time ran nearly 1000 times faster than it actually did).

When pilot code (for the enormously bloated PKI/certificate specification) was 
finally available, using BSAFE library (speedup enhancements had been 
incorporated into standard distribution) ... dedicated pilot demos for 
transaction round trip took nearly minute elapsed time ... effectively all of 
it was BSAFE computations (using dedicated computers doing nothing else).

Merchants that found using SSL for the whole consumer interaction would have 
required ten to twenty times the number of computers ... to handle equivalent 
non-SSL load ... were potentially being faced with needing hundreds of 
additional computers to handle just the BSAFE computational load (for the 
mentioned extremely PKI/certificate bloated payment specification) ... and 
still wouldn't be able to perform the transaction anywhere close to the elapsed 
time of the implementation being used with SSL.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-08-01 Thread Anne Lynn Wheeler

On 07/28/2010 08:55 AM, Anne  Lynn Wheeler wrote:

disclaimer: the inventor of domain name infrastructure did a stint at the 
science center a decade earlier
 ... working on various and sundry projects.


other public key  science center trivia; former RSA CEO also at science center 
... following
recent entry from his blog:
http://smartphonestechnologyandbusinessapps.blogspot.com/2010/05/bob-creasy-invented-virtual-machines-on.html

lots of past posts mentioning science center, 4th flr, 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech

a couple old emails from 1981 ... discussing a certificate-less, PGP-like 
implementation for the internal network
http://www.garlic.com/~lynn/2007d.html#email810506
http://www.garlic.com/~lynn/2006w.html#email810515

... aka the internal network was larger than the arpanet/internet from just 
about the beginning until sometime late '85 or early '86. one big difference 
from arpanet/internet was corporation required all links to be encrypted ... 
and in the mid-80s there
was the claim that the internal network had over half of all hardware link 
encryptors in the world ... only practical solution at the time. I was running 
multiple T1 links in the period ... and DES-encryption processing for sustained 
full-duplex traffic from a single T1 link was more than enough to consume 
multiple mainframe processors. old email on the subject (regarding doing some 
benchmarking of DES software encrypt/decrypt)
http://www.garlic.com/~lynn/2006n.html#email841115

past posts mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Five Theses on Security Protocols

2010-07-31 Thread Anne Lynn Wheeler

corollary to security proportional to risk is parameterized risk management 
... where variety of technologies with varying integrity levels can co-exist within the same 
infrastructure/framework. transactions exceeding particularly technology risk/integrity threshold 
may still be approved given various compensating processes are invoked (allows for multi-decade 
infrastructure operation w/o traumatic dislocation moving from technology to technology as well as 
multi-technology co-existence).

in the past I had brought this up to the people defining V3 extensions ... 
early in their process ... and they offered to let me do the work defining a V3 
integrity level field. My response was why bother with stale, static 
information when real valued operations would use much more capable dynamic, 
realtime, online process.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI, Part II

2010-07-30 Thread Anne Lynn Wheeler

On 07/28/2010 11:52 PM, Pat Farrell wrote:

A lot of the smart card development in the mid-90s and beyond was based
on the idea that the smart card, in itself, was the sole authorization
token/algorithm/implementation.


some ssl, payment, smartcard trivia ...

those smartcards were used for the offline authorization (not just authentication) ... which, in at least one 
major product, led to the YES CARD ... relatively trivial to skim  replicated a static digital 
certificate for a counterfeit card ... then the counterfeit card was programmed to answer YES to 1) 
was the correct PIN entered, 2) should the transaction be performed offline, and 3) was the transaction approved. 
Once the static digital certificate was skimmed, it was no longer even necessary to know the PIN, since the 
counterfeit card accepted every possible PIN as valid. misc. past posts mentioning YES CARD
http://www.garlic.com/~lynn/subintegrity.html#yescard

In a 2003, at an ATM Integrity task force meeting ... there was presentation by some LEO explaining the yes 
card ... and how there was little or no countermeasure once a YES CARD was in existence ... somebody 
in the audience loudly observed that billions were spent on proving smartcards are less secure than magstripe. In the 
YES CARD timeframe there was even a rather large pilot of the cards in the US ... but seemed to disappear 
after the YES CARD scenario was publicized (it was actually explained to the people doing the pilot, before 
the pilot started ... but apparently they didn't appreciate the significance).

much earlier, we had been working on our ha/cmp product and cluster scaleup. we 
had meeting on cluster scaleup meeting during jan92 sanfran usenet (in 
ellison's conference room) ... past posts mentioning the jan92 meeting
http:www/garlic.com/~lynn/95.html#13

this was just a few weeks before cluster scaleup was transferred (announced as 
supercomputer for numerical intensive only) and we were told we couldn't work 
on anything with more than four processors. some old email from the period on 
cluster scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa

we then leave a couple months later. two of the other people named in the jan92 meeting also leave and show 
up at small client/server startup responsible for something called commerce server. we get 
brought in to consult because they want to do payment transactions on the server ... the small client/server 
startup has also invented some technology called SSL they want to use. The results is now 
frequently called electronic commerce.

Then apparently because of the work on electronic commerce ... we also get 
invited to participate in the x9a10 financial standard working group ... which 
had been given the requirement to preserve the integrity of the financial 
infrastructure  for all retail payments.

About the same time there is a pilot program for magstripe-based online 
stored-value cards  (uses existing POS magstripe terminals but the payment 
network routes the transactions to different backend processor, original 
program of its kind in the US). At the time, the US didn't have the telco 
connectivity availability and cost issues that many places in the rest of the 
world were dealing with ... and therefor didn't have that requirement to move 
to offline smartcard payment paradigm. However, it turns out their backend, 
high-availability, no-single-point-of-failure platform developed a glitch ... 
and even tho it was from a different vendor (than our ha/cmp product) we were 
asked to investigate at the various failure modes.

Somewhat as a result of all of the above, when one of the major offline, 
smartcard, european, stored-value payment operators was looking at making an 
entry into the US in the 90s ... we were asked to design, size, and cost their 
backend dataprocessing infrastructure. Along the way, we took an indepth look 
at the business process and cost structure of such payment products. Turns out 
that the major financial motivation for that generation of smartcard 
stored-value payment products ... was that the operators got to keep the float 
on the value resident in the stored-value cards. Not too long later ... several 
of the major european central banks announced that the smartcard, stored-value 
operators would have to start paying interest on value in the smartcards 
(eliminating the float financial incentive to those operators). It wasn't too 
long after that most of the programs disappeared.

The major difference between that generation of smartcard payment products and the AADS chip 
strawman ... was that rather than attempting to be a complex, loadable, multi-function issuer card 
 the objective was changed to being a person-centric, highest-possible integrity, 
lowest-possible cost, hard-to-counterfeit authentication ... which could be registered (publickey) 
for arbitrary number of different environments (something you have authentication 
registered in manner analogous to 

Re: A mighty fortress is our PKI, Part II

2010-07-29 Thread Anne Lynn Wheeler

On 07/28/2010 11:52 PM, Pat Farrell wrote:

I'd like to build on this and make a more fundamental change. The
concept of a revocation cert/message was based on the standard practices
for things like stolen credit cards in the early 1990s. At the time, the
credit card companies published telephone book sized listings of stolen
and canceled credit cards. Merchant's had the choice of looking up each
card, or accepting a potential for loss.

A lot of the smart card development in the mid-90s and beyond was based
on the idea that the smart card, in itself, was the sole authorization
token/algorithm/implementation.



that was one of my points ridiculing PKI in the mid-90s ... that the CRL was a 
return to offline point-of-sale payment operation ... and seemed to motivate 
the work on OCSP.

The difference was that in the move to real-time online transactions ... it got 
much high quality operation ... not only could it establish real-time 
valid/not-valid ... but also other real-time characteristics like real-time 
credit limit, recent pattern of transactions, and much more. by comparison, 
OCSP was an extremely poor man's real-time, online transaction

smartcard payment cards started out being stand-alone stored-value to 
compensate for the extremely expensive and limited availability of 
point-of-sale in much of the world ... aka it was stored-value operation where 
the operation could be performed purely offline (the incremental cost of the 
smartcard chip was offset by savings not requiring realtime, online 
transaction).

The telco economics didn't apply to the US ... as seen by the introduction of 
stored-value magstripe based payment cards in the US that did real-time, online 
transaction ... which served the same market niche that the offline smartcard was performing 
in other parts of the world. Between the mid-90s and now, telco costs  connectivity has 
significantly changed around the world ... pervasive uniquitness of the internet, cellphone 
coverage, wireless, ... lots of things.

The common scenario in the past couple decades ... was looking to add more  
more feature/function to smartcards to find the magical economic justification ... 
unfortunately, the increase in feature/function tended to also drive cost ... 
keeping the break even point just out of reach.

Part of the certificateless public key work was to look at chips as a cost item (rather 
than profit item ... since lots of the smartcard work was driven by entities looking to 
profit by smartcard uptake). The challenge was something that had stronger integrity 
than highest rated smartcard but at effective fully loaded cost below magstripe (i.e. I 
had joked about taking a $500 milspec part, cost reducing by 3-4 orders of magnitude 
while improving the integrity). Another criteria was that it had to work within the 
time  power constraints of a (ISO14443) contactless transit turnstyle ... while 
not sacrificing any integrity  security.

By comparison ... one of the popular payment smartcards from the 90s looked at the transit 
turnstyle issue ... and proposed a wireless sleeve for their contact card ... and 15ft 
electromagnetic tunnels on the approach to each transit turnstyle ... where public 
would walk slowly thru the tunnel ... so that the transaction would have completed by the time the 
turnstyle was reached.

Part of achieving lower aggregate cost than magstripe ... was that even after 
extremely aggressive cost reduction, the unit cost was still 2-3 times that of 
magstripe ... however, if the issuing frequency could be reduced (for chip)... 
it was more than recouped (i.e. magstripe unit cost is possibly only 1% of 
fully loaded issuing costs). Changing the paradigm from institutional-centric 
(i.e. institution issued) to person-centric (i.e. person uses the same unit for 
multiple purposes and with multiple institutions) ... saves significant amount 
more (replaces an issuing model with a registration model).

Turns out supposedly a big issue for a transition from an institution-centric (institution issuing) 
to person-centric paradigm ... was addressing how can the institution trust the unit 
being registered. Turns out that trust issue may have been obfuscation ... after 
providing a solution to institution trust ... there was continued big push back to moving off an 
institutional issuing (for less obvious reasons) ... some of the patent stuff (previous mentions) 
covered steps for moving to person-centric paradigm (along with addressing institutional trust 
issues). Part of it involved tweaking some of the processes ... going all the way back to while the 
chip was still part of wafer (in chip manufacturing ... and doing the tweaks in such a way that 
didn't disrupt standard chip manufacturing ... but at the same time reduced steps/costs).

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List

Re: A slight modification of my comments on PKI.

2010-07-29 Thread Anne Lynn Wheeler

On 07/28/2010 10:34 PM, d...@geer.org wrote:

The design goal for any security system is that the number of
failures is small but non-zero, i.e., N0.  If the number of
failures is zero, there is no way to disambiguate good luck
from spending too much.  Calibration requires differing outcomes.
Regulatory compliance, on the other hand, stipulates N==0 failures
and is thus neither calibratable nor cost effective.  Whether
the cure is worse than the disease is an exercise for the reader.


another design goal for any security system might be security proportional to 
risk. the major use of SSL in the world today is hiding financial transaction 
information ... currently mostly credit card transactions. One of the issues is that the 
value of the transaction information to the merchants (paying for majority of the 
infrastructure) is the transaction profit ... which can be a dollar or two. The value of 
the transaction information to the attackers is the associated account limit/balance, 
which can be several hundred to several thousand dollars. This results in a situation 
where the attackers can afford to outspend the defenders by 100 times or more.

somewhat because of the work on the current payment transaction infrastructure 
(involving SSL, by the small client/server startup that had invented SSL), in 
the mid-90s, we were invited to participate in the x9a10 financial standard 
working group (which had been given the requirement to preserve the integrity 
of the financial infrastructure for all retail payments). the result was the 
x9.59 financial transaction standard. Part of the x9.59 financial transaction 
standard was slightly tweaking the paradigm and eliminating the value of the 
transaction information to the attackers ... which also eliminates the major 
use of SSL in the world today. It also eliminates the motivation behind the 
majority of the skimming and data breaches in the world (attempting to obtain 
financial transaction information for use in performing fraudulent financial 
transactions). note the x9.59 didn't do anything to prevent attacks on SSL, 
skimming attacks, data breaches, etc ... it just eliminated the
major criminal financial motivation for such attacks.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A slight modification of my comments on PKI.

2010-07-29 Thread Anne Lynn Wheeler

for the fun of it ... from today ...

Twenty-Four More Reasons Not To Trust Your Browser's Padlock
http://blogs.forbes.com/firewall/2010/07/29/twenty-four-more-reasons-not-to-trust-your-browsers-padlock/?boxes=Homepagechannels

from above:

On stage at the Black Hat security conference Wednesday, Hansen and Sokol 
revealed 24 new security issues with SSL and TLS, the digital handshakes that 
browsers use to assure users they're at a trusted site and that their 
communication is encrypted against snoops.

... snip ...

adding further fuel to long ago motivation that prompted me to coin the term 
merchant comfort certificates.

... as an aside, we were tangentially involved in the cal. data breach notification legislation. we had 
been brought in to help wordsmith the cal. electronic signature act ... and some of the participants 
were heavily involved in privacy issues. They had done in-depth consumer privacy studies and the number 
one issue came up identity theft, namely the account fraud form where criminals 
use account /or transaction information (from data breaches) to perform fraudulent financial 
transactions. It appeared that little or nothing was being done about such data breaches ... and they 
appeared to believe that the publicity from the data breach notifications would motivate corrective 
action to be taken (and as mention in previous post ... we took a slightly different approach to the 
problem in the x9.59 financial transaction standard ... eliminating the ability of crooks to use such 
information for fraudulent transactions).

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-28 Thread Anne Lynn Wheeler

On 07/28/2010 12:10 AM, Paul Tiemann wrote:

I like the idea of SSL pinning, but could it be improved if statistics were 
kept long-term (how many times I've visited this site and how many times it's 
had certificate X, but today it has certificate Y from a different issuer and 
certificate X wasn't even near its expiration date...)

Another thought: Maybe this has been thought of before, but what about 
emulating the Sender Policy Framework (SPF) for domains and PKI?  Allow each 
domain to set a DNS TXT record that lists the allowed CA issuers for SSL 
certificates used on that domain.  (Crypto Policy Framework=CPF?)

cpf.digicert.com IN TXT v=cpf1 /^DigiCert/ -all

Get the top 5 browsers to support it, and a lot of that any CA can issue to any 
domain risk goes way down.

Thought: Could you even list your own root cert there as an http URL, and get 
Mozilla to give a nicer treatment to your own root certificate in limited scope 
(inserted into some kind of limited-trust cert store, valid for your domains 
only)

Is there a reason that opportunistic crypto (no cert required) hasn't been done 
for https?  Would it give too much confidence to people whose DNS is being 
spoofed?


Part of SSL was countermeasure to perceived weakness in domain name 
infrastructure ... is the server that I think I'm talking to really the server 
I'm talking to (things like ip-address hijacking). Now Certification 
Authorities typically aren't the authoritative agency for the information they 
are certifying ... they ask for a whole bunch of information from an SSL 
certificate applicant and then perform and expensive, time-consuming, and 
error-prone identification process, x-checking the supplied information with 
the information on-file at the domain name infrastructure as to the true owner 
of a domain (the same domain name infrastructure that has the weaknesses that 
SSL is designed as countermeasure).

So ... something that could be backed by the Certification Authority industry 
as part of DNSSEC is to ask that all domain name applicants also register a 
public key as part of obtaining a domain name. domain name infrastructure then 
can required that all subsequent communication be digitally signed ... and can 
be verified with the onfile public key (as countermeasure to various kinds of 
domain name hijacking exploits, hijack domain and then apply for valid SSL 
certificate using dummy front company which matches the corrupted onfile 
information). The Certification Authority industry then could take advantage of 
the same infrastructure and require that all SSL domain name certificate 
applications, also be digitally signed (and can be verified with the onfile 
public key at the domain name infrastructure); replacing a time-consuming, 
expensive, error-prone identification process with an efficient, inexpensive, 
reliable authentication process.

The catch-22 for the industry is if the Certification Authority industry could 
start doing real-time, online retrieval of public keys for authentication ... 
then maybe the rest of the world might also ... changing SSL to a 
certificateless, real-time, online publickey infrastructure.

One of the possible reasons that it hasn't happened is there no startup, venture capital, 
IPO ... etc, gorp associated with such an incremental enhancement to the existing domain 
name infrastructure (it is a pure security/integrity play with no big financial 
motivation for anybody). W/o startup, venture capital, IPO play ... there is no big 
marketing budget to blitz the public on how much more comforting things would be (i.e. 
part of the reason that I coined the term merchant comfort certificates back 
in the early days). In the late 90s, we got visited by somebody that wanted to explain 
about the downside our comments could have on some pending Certification Authority IPO 
(much of internet hype from the period was actually part of IPO-mill money generating 
machine).

I've posted frequently in the past about the catch-22 scenario for the 
certification authority industry.

disclaimer: the inventor of domain name infrastructure did a stint at the 
science center a decade earlier ... working on various and sundry projects.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI, Part II

2010-07-28 Thread Anne Lynn Wheeler

On 07/28/2010 10:05 AM, Perry E. Metzger wrote:

I will point out that many security systems, like Kerberos, DNSSEC and
SSH, appear to get along with no conventional notion of revocation at all.
 
long ago and far away ... one of the tasks we had was to periodically go by project athena to audit various activities ... including Kerberos. The original PK-INIT for kerberos was effectively certificateless public key ... aka replace registering a shared-secret password (for authentication) with a public key. There was then some amount of lobbying by the certification authority interests for pk-init to include certificate-based mode of operation (I wrote the draft-words for PK-INIT for inclusion of certificateless ecdsa).


An issue with Kerberos (as well as RADIUS ... another major authentication 
mechanism) ... is that account-based operation is integral to its operation ... 
unless one is willing to go to a strictly certificate-only mode ... where all 
information about an individuals authority and access privileges are also 
carried in the certificate (and eliminate the account records totally).

As long as the account record has to be accessed as part of the process ... the 
certificate remains purely redundant and superfluous (in fact, some number of 
operations running large Kerberos based infrastructure have come to realize 
that they have large redundant administrative activity maintaining both the 
account-based information as well as the duplicate PKI certificate-based 
information).

The account-based operations have sense of revocation by updating the 
account-based records. This can be done in real-time and at much finer levels 
of granularity than the primitive, brute-force (PKI) revocation (and 
replacement). For instance, have you gone over your outstanding balance or 
credit-limit? ... are you up-to-date with you ISP account? ... or should it 
just be temporarily suspended bending receipt of funds. Account records can 
carry other kinds of real-time information ... like whether currently logged on 
... and should duplicate, simultaneous logons be prevented (difficult to 
achieve with redundant and superfluous, stale, static certificates).

The higher-value operations tend to be able to justify the real-time, higher 
quality, and finer grain information provided by an account-based 
infrastructure ... and as internet and technology has reduced the costs and 
pervasiveness of such operations ... it further pushes PKI, certificate-based 
mode of operation further and further into no-value market niches.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI, Part II

2010-07-28 Thread Anne Lynn Wheeler

On 07/28/2010 11:05 AM, Nicolas Williams wrote:

Are you arguing for Kerberos for Internet-scale deployment?  Or simply
for PKI with rp-only certs and OCSP?  Or other federated
authentication mechanism?  Or all of the above?  :)


as i've mentioned ... the relying-party-only certificates are almost always 
redundant and superfluous ... except in cases where the relying party can't 
justify their own repository of information and/or distributed access to such a 
repository of information.

I previously mentioned that in the payment transaction case, even a 
relying-party-only certificate was a factor of 100-times payload size bloat for 
typical payment transactions ... aka not only was the certificate redundant and 
superfluous ... but it represented an enormous (redundant and superfluous) 
processing burden.

I've mentioned a number of times that OCSP appeared after I had repeatedly ridiculed 
revokation process being archaic backwards step for real-time payment processes. And that 
even OCSP (with a certificate) is still redundant and superfluous when real-time 
transaction is being performed using the real information.

the other scenario for rpo-certs ... besides for no-value operations ...  is 
when the real infrastructure is down and/or not accessible. But that usually is 
matter of cost also, some of the higher-value operations have gone to 
significant redundancy and claim 100% availability. The certificate analogy is 
still the letters of credit/introduction from sailing ship days ... when the 
relying-party had no (other) access to first time interaction with complete 
stranger (and has to fall back to much cruder and lower quality information).

There is also some scenario if the respository and the service are co-located 
... that when the repository is unavailable the service will also be 
unavailable ... so there is no requirement for independent source of 
information.

The catch22 for certification authority operation ... is that as they move further 
 further into the no-value market niches (and/or market niches that can't 
justify the expense of higher quality operation with real-time repository) ... they 
are forced to cut their fees and indirectly the quality of their operation.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI, Part II

2010-07-28 Thread Anne Lynn Wheeler

On 07/28/2010 12:02 PM, Nicolas Williams wrote:

Sorry, but this is wrong.  The OCSP protocol itself really is an online
certificate status protocol.  Responder implementations may well be
based on checking CRLs, but they aren't required to be.

Don't be confused by the fact that OCSP borrows some elements from CRLs.


my OCSP analogy was turning authentication into an end in itself ... basically 
a new kind of retail store ... instead of retail store that sells some product 
... you go in and buy something ... doing a real-time payment transaction; ... 
there is an authentication store ... convince everybody that they need to walk 
into their (OCSP) authentication retail store at least once a day to perform an 
authentication operation (for no other reason that people should get a lot of 
comfort out of being authenticated at least once a day or more if necessary) 
... totally divorced and unrelated to any actual business purpose.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Anne Lynn Wheeler

On 07/27/2010 10:11 AM, Peter Gutmann wrote:

So a general response to the several well, what would you do? questions is
I'm not sure, that's why I posted this to the list.  For example should an
SSL cert be held to higher standards than the server it's hosted on?  In other
words if it's easier to compromise a CDN host or (far more likely) a web app
on it, does it matter if you're using a Sybil cert?  I have no idea, and I'm
open to arguments for and against.


long ago and far away, we were called in to consult with a small client/server startup that wanted 
to do payment transactions on their server ... they had also invented this technology called SSL 
that they wanted to use. As part of applying the technology to the business payment process ... we 
also had to go around and investigate how some of these new businesses, calling themselves 
Certification Authorities, operated. In any case, the result is now sometimes called 
electronic commerce.

There were lots of issues with deficiencies and vulnerabilities, resulting in my coining 
the term merchant comfort certificates ... aka ... as opposed to anything to 
do with security. Of course, I also suggested that everybody that in anyway touched on 
the certificates or the merchant servers ... needed to have detail FBI background check.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI

2010-07-27 Thread Anne Lynn Wheeler

On 07/27/2010 12:09 PM, Pat Farrell wrote:

Most of which we avoided by skipping the cert concept. Still, better
technology has nothing to do with business success.

Public Key Crypto with out all the cruft of PKI. Its still a good
idea.


that became apparent in the use of SSL between all the merchant servers and the 
payment gateway. by the time the registration and setup process was completed 
at both ends ... the certificate was purely an artificial attribute of the 
crypto library being used. there were other issues with the payment gateway 
protocol ... i was able to mandate things like mutual authentication ... which 
didn't exist in the crypto library up to that point ... however the exchange of 
certificates was so engrained that it wasn't possible to eliminate (even tho 
all the necessary information already existed at both end-points).

the merchant server/browser part ... I could only recommend ... I couldn't 
mandate.

my analogy is that certificates  PKI are electronic analogy of the letters of 
credit/introduction from the sailing ship days ... when the relying party had no 
other recourse for information about the stranger that they were dealing with. This 
was left over from the dail-up email days of the early 80s (dial-up electronic 
post-office, exchange email, hangup, and possibly have first-time email from 
complete stranger).

that design point was quickly vanishing in the 90s with the pervasive growth of 
the online internet.

I as at annual ACM sigmod conference in the early 90s ... and one of the big 
sessions, somebody asked on of the panelists what was all this x.50x gorp about. 
Eventually somebody explained that it was a bunch of networking engineers 
attempting to re-invent 1960s database technologies  with certificates being 
armored, stand-alone, stale representation of some information from a database 
someplace. In the later 90s, certificates attempted to find place in no-value 
market niches (aka, situations involving no-value operations that couldn't justify 
online /or real-time information) ... although this got into some conflicts 
... trying to address no-value market-niche ... at the same time claiming 
high-value, expensive operation.

There were businesses cases floated to venture community claiming $20B 
certificate market ... i.e. that every person in the country would have 
$100/annum certificate ... some predicting that the financial community would 
underwrite the cost. When that didn't happen, there were other approaches. We 
had been called in to help wordsmith the cal. state electronic signature 
legislation ... which was being heavily lobbied by the PKI industry to mandate 
certificates.

I could that rube-goldberg OCSP was response to interaction I had with some of 
the participants ... somebody bemoaning the fact that the financial industry 
needed to be brought into 20th century requiring certificates appended to every 
financial transaction. I responded that stale, static certificates would be 
retrenching to before the advent of online, real-time point-of-sale payment 
transactions ... aka a major step backward, not a step forward.

Besides the appending a stale, static certificate to every payment transaction being 
redundant and superfluous ... it also represents enormous overhead bloat. There were some 
reduced financial, relying-party-only certificates being floated in the 
mid-90s ... which were still 100 times larger than the typical payment payload size 
(increase the size of payment transaction payload by a factor of 100 times for no 
beneficial purpose).

The X9 financial standard group ... had some participants recognizing the 
enormous overhead bloat certificates represented in payments started a 
compressed certificate standards activity ... possibly looking to reduce the 
100 times overhead bloat to only 5-10 times overhead bloat (although still 
redundant and superfluous). One of their techniques was that all information 
that was common in every certificate ... could be eliminated. Then all 
information that the relying party already had could be eliminated. I was able 
to trivial show, that a relying party would have access to every piece of 
information in a certificate ... and therefor digital certificates could be 
compressed to zero bytes.

Then rather than arguing whether it was mandated that every payment transaction 
have an appended certificate ... we could mandate that every payment 
transaction have a zero-byte appended certificate.

disclaimer ... eventually had a couple dozen (assigned, retain no interest) 
patents in the area of certificate-less public key (some showing up long after 
we were gone) ... summary here
http://www.garlic.com/~lynn/aadssummary.htm

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com



Re: A mighty fortress is our PKI

2010-07-27 Thread Anne Lynn Wheeler

On 07/27/2010 12:09 PM, Pat Farrell wrote:

In that same time, I was at CyberCash, we invented what is now
sometimes called electronic commerce.  and that and $5 will get
you a cup of coffee. We predated SSL by a few years. Used RSA768 to
protect DES sessions, etc. Usual stuff.


somewhat as result of doing the SSL payment stuff ... in the mid-90s got invited to 
be part of the x9a10 financial standard working group ... which had been given the 
requirement to preserve the integrity of the financial infrastructure for all 
retail payments. the result was x9.59 retail payment financial standard ... which 
was specific in such a way that it would work with any secure authentication 
(including allowing both certificate  certificate-less mode). The business 
process was slightly tweaked so it was no longer necessary to hide the information 
in a payment transaction to preserve the financial infrastructure integrity. This 
didn't eliminate skimming, evesdropping, data breaches ... but it eliminated the 
ability for the attackers to use the information to perform fraudulent transactions 
(and effectively also eliminates the major use of SSL in the world ... hiding the 
information in financial transaction).

About the same time the x9a10 standards work was going on ... there were a 
couple other payment transaction specification work occurring ... which were 
mandating certificate operation ... somewhat trying to side-step the 100 times 
payload bloat. they would strip the certificate at internet gateway ... and 
forward the transaction thru the standard payment network with flag turned on
(they could somewhat wave their hands that 100 times payload bloat on the internet was 
immaterial ... but not so in the real payment network) that certificate processing had 
occurred (compared to light-weight, super secure, x9.59 ... which operated end-to-end). 
There were later some presentations at ISO standards meetings that transactions were 
showing up with the certificate flag on ... but they could prove no 
certificate had been involved (i.e. there was financial interchange fee benefit 
motivating turning on the flag).

shortly after they had published their (certificate-based) payment 
specification (but well before any operational code), I did a public-key op 
profile for their specification. I then got a friend that had a optimized BSAFE 
library (ran four times faster) to benchmark the profile on lots of different 
platforms ... and then reported the results to the groups publishing the 
profile. The response was my numbers were 100 times too slow (if they had 
actually run any numbers, their comment should have been it was four times too 
fast). Some six months later when they did have pilot code ... my profile 
numbers were within a couple percent of actual (i.e. the BSAFE library changes 
had been incorporated into standard distribution).

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


GOST RFCs 5830, 5831, 5832

2010-03-17 Thread Anne Lynn Wheeler

welcome back

announcement of RFC 5830, 5831,  5832 in today's RFC distribution

abstract for 5830:

This document is intended to be a source of information about the
Russian Federal standard for electronic encryption, decryption, and
message authentication algorithms (GOST 28147-89), which is one of the
Russian cryptographic standard algorithms called GOST algorithms).
Recently, Russian cryptography is being used in Internet applications,
and this document has been created as information for developers and
users of GOST 28147-89 for encryption, decryption, and message
authentication.  This document is not an Internet Standards Track
specification; it is published for informational purposes.

--
42yrs virtualization experience (since Jan68), online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Crypto dongles to secure online transactions

2009-11-25 Thread Anne Lynn Wheeler

On 11/21/2009 04:56 PM, John Levine wrote:

we claimed we do something like two orders magnitude reduction in
fully-loaded costs by going to no personalization (and other things)
...


My concern with that would be that if everyone uses the the same
signature scheme and token, the security of the entire industry
becomes dependent on the least competent bank in the country not
leaking the verification secret.

For something like a chip+pin system it is my understanding that the
signature algorithm is in the chip and different chips can use
different secrets and different algorithms, so a breach at one bank
need not compromise all the others.

R's,
John



there is no shared secret ... there is unique chip private/public key generated at power-on/test  
and the public key was included/transmitted with the test result data as part of the initial power-on/test

cycle (this is process that occurs while the chips are still in wafer ... before 
being sliced  diced).
the silicon is designed to never (volunteerly) divulge the private key (modulo 
some extremely heavy duty physical attacks).

the patent stuff was all done for employer as assigned patents quite awhile ago 
(we've been gone for several yrs and the patent stuff keeps going on).

initially there was a large number of claims and had gotten to packaged as over 
60 patents and looked to be 100 before we were done. about that point, the 
employer looks at filing costs in the US and international ... and directs that 
all the claims be packaged as nine patents. Later, the patent office comes back 
and makes some comment about getting tired of huge patents where the filing fee 
doesn't even cover the cost of reading all the claims ... and directed that the 
claims be packaged as larger number of claims.
http://www.garlic.com/~lynn/aadssummary.htm

while there are claims related to unique devices with unique digital signatures 
in other applications ... there was a patent application (in our name ... years 
after we are gone) this year
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220090158029%22.PGNR.OS=DN/20090158029RS=DN/20090158029

all the initial chips were ec/dsa (each chip with its own unique public/private 
key) ... all done in fab that had security certified by US, EU  other gov. 
institutions and also financial institutions (no compromised chips substituted for 
real ones) ... I even got to walk the fab in bunny suit doing my own certification.

if you want different algorithms (or key lengths) ... you have to cut a new 
mask and make different wafer runs. if the number of wafers in wafer runs are 
too small ... you would start to drive the cost/chip above a few cents. There 
is no single-point-of-compromise. Compromising a single chip is equivalent to 
skimming a single magstripe ... can do fraudulent transactions against the 
accounts for that chip/token (and chip compromise significantly more difficult 
than magstripe skimming).

In theory there might be weakness found in specific chip or specific algorithm 
... but design allows for a large number of different chips and algorithms to 
interoperate in the same environment. For the initial chips ... I got a EAL4+ 
common criteria certification (by accredited lab in germany). I wanted a higher 
certification ... but had a problem that EC/DSA verification suite had been 
withdrawn. There were some higher certifications on similar chips by others 
...but their design involved loading the crypto after the certification (they 
got certification done on chip before any software loaded). My chip had 
everything in silicon (all feature/functions) ... and so the certification was 
done on everything that would be in actual use.

in the person-centric scenario ... each chip's private key becomes somewhat akin to fingerprint 
or iris pattern ... a unique something you have ... as opposed to unique something you 
are (and much easier to replace/change if there is a specific compromise).

some of the patents cover not only recording public key for each account the 
corresponding token is authorized for (and multiple different tokens might be 
authorized for same account) ... but also knowledge about the assurance level 
of the related chip. Real-time updates are then available about chip assurance 
level ... and real-time authorizations can not only take into account whether 
the transaction is within the account balance ... but potentially is the 
assurance level of the chip is high enough for authorizing the transaction.

X9.59 financial standard transaction protocol also allows for the environment 
that the transaction is performed in to also sign the transaction (in addition 
to the person's chip). Real-time authorization then may take into account both 
the assurance level (potentially updated in real-time) of the user's chips as 
well as the assurance level of the transaction environment (in determining if 
there is sufficient 

Re: Crypto dongles to secure online transactions

2009-11-25 Thread Anne Lynn Wheeler

On 11/21/2009 05:56 PM, Jerry Leichter wrote:

On Nov 18, 2009, at 6:16 PM, Anne  Lynn Wheeler wrote:

... we could moved to a person-centric paradigm ... where a person
could use the same token for potentially all their interactions ...
we claimed we do something like two orders magnitude reduction in
fully-loaded costs by going to no personalization (and other things)
... and then another two orders magnitude reduction in number of
tokens by transitioning from institutional-centric paradigm to
person-centric paradigm (compared to proposed smartcard/dongle
replacing every pin/password).

we then came up against that the bank marketing departments have taken
advantage of the requirement for institutional personalization ... to
put their brand and other stuff on every token

It goes deeper than that. Oh, sure, marketing loves having a presence -
but their desire fits into corporate cultural biases.

When I go to work, I have to carry two key cards - one for the building,
one for my employer. They use the same technology - if you use the wrong
one, the reader beeps in recognition but of course won't unlock the
door. In fact, they interfere with each other - you have to make sure to
keep the wrong one a couple of inches away from the reader or it will
usually be confused. It's a pain, actually.

Now, it's certainly possible that there's something proprietary on one
card or the other - though as we've discussed here before, that's only
true on badly designed systems: It's no big deal to read these cards,
and from many times the inch or so that the standard readers require. So
all that should be on the cards is an essentially random number which
acts as a key into the lock systems database. It's just that the owners
of each system insist on assigning that random number themselves. Does
it give them any additional security? Hardly. If you think through the
scenarios, you confirm that quickly - a direct consequence of the lack
of any inherent value in the card or its contained number in and of
themselves: The real value is in the database entry, and both
institutions retain control of their own databases.

What's needed is some simple cooperation and agreement on how to assign
unique numbers to each card. There already has to be cooperation on the
issuance and invalidation of building cards. But institutions insist on
their sense of control and independence, even when it has no real
payoffs for them (and, in fact, raises their costs).
-- Jerry


We went thru all the scenarios with the objections on why they wanted 
institutional-centric paradigm ... part of the scenario was putting the 
assurance level of the chip on level with assurance level of your fingerprint 
or iris pattern ... and asking when institutions were going to start issuing 
individual, institutional-specific fingers for people to use.

this is various person-centric claims here and there  (assigned and still 
having activity after we've been gone for yrs)
http://www.garlic.com/~lynn/aadssummary.htm

there is specific granted patent here:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PALLp=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmr=1f=Gl=50S1=6978369.PN.OS=PN/6978369RS=PN/6978369

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Crypto dongles to secure online transactions

2009-11-25 Thread Anne Lynn Wheeler

On 11/21/2009 06:31 PM, Jerry Leichter wrote:

Well, my building card is plain white. If anyone duplicated it, there'd be nothing 
stopping them from going in. But then the actual security offered by those cards - and 
the building controls - is more for show (and I suppose to keep the riffraff 
out - than anything else.

My work card has my photo and name on it, but there's nothing to correlate name 
with underlying ID in normal operation. Snap a photo of the card while you 
clone it, make up a reasonable simulacrum with your own picture and name, and 
walk right in.

Not really more or less secure than the old days when you flashed you (easily 
copied) badge to a card who probably only noticed that it was about the right 
size and had roughly the right color. But it's higher tech, so an improvement. 
:-)

Physical security for most institutions has never been very good, and 
fortunately has never *needed* to be very good. Convenience wins out, and 
technology gives a nice warm feeling. A favorite example: My wife's parents 
live in a secured retirement community. The main entrance has a guard who 
checks if you're on a list of known visitors, or calls the people you're 
visiting if not. Residents used to have a magnetic card, but that's a bit of 
pain to use. So it was replaced by a system probably adapted from railroad 
freight card ID systems: You stick big barcode in your passenger side window, 
and a laser scanner on a post reads it and opens the door.


Simplest card/token is basically (single-factor) something you  have  
authentication

the cheapest RFID proximity card is just some static data ... that can be trivially copied and reproduced ... think of it somewhat akin to a 
wireless magstripe. that has also the YES CARD point-of-sale contact card vulnerability. Compromised POS terminal that recorded the 
static data from card transaction and trivially used to produce a counterfeit card (little or no difference from compromised POS terminal that 
records magstripe data). What made it worse than magstripe was that POS terminals were programmed to ask a validated chip three questions 1) was the entered 
PIN correct, 2) should the transaction be done offline, and 3) is the transaction within the account credit limit. A counterfeit YES CARD would 
answer YES to all three questions (it wasn't necessary to even know the correct pin with counterfeit YES CARD ... and deactivating the 
account ... as in magstripe ... wasn't sufficient to stop the fraud). A counterfeit YES CARD was also some other counterme
asures that had been built into the infrastructure:
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

a little more secure is two-factor token that requires both the token and possibly 
something you know. However, two-factor authentication is assumed more secure 
is based on single factor authentication is based on
the different factors having independent compromises. In the case of the YES 
CARD (supposedly two-factor) ... it was only necessary to compromise the token's 
static data ... and it wasn't even necessary to know the correct PIN. In the case of 
pin-debit cards ... skimming compromises of ATMs or point-of-sale terminals can collect 
both the PIN and the magstripe data at the same time (invalidating assumption about 
independent compromises).

we had somewhat been asked in the mid-90s to participate in the x9a10 financial standard 
group (which had been given the requirement to preserve the integrity of the financial 
infrastructure for all retail payments) because of having worked on this stuff now 
frequently called electronic commerce. This was *ALL* as in debit, credit, 
ACH, internet, point-of-sale, low-value, high-value, face-to-face, unattended, and/or 
transit. Transit-turnstyle has similar requirements to building access ... although the 
contactless power limitations and contactless elapsed time requirements can be more 
stringent than building access.

Somewhat as a result ... the related work on the AADS chip strawman, had all sorts of 
requirements ... form factor agnostic, very-very fast, very-very low-power, contactless 
capable ... but for high-value ... had to no have *NO* static data and very 
difficult to counterfeit ... but at the same time ... for low-value ... had to have as 
close to zero cost as possible.

Most of the alternatives from the period ... tended to only consider a very small subset of those 
requirements ... and therefor created a solution that had a single, specific operation and were ill-suited 
for a general purpose use. A simple issue was having the same token that was multi-factor authentication 
agile ... operate with single-factor (something you have) at a transit turnstyle (no time to enter PIN) ... 
but works the same way at a high-security building access turnstyle that requires multi-factor authentication 
(something you have token in conjunction with PIN something-you-know or palm 
finger 

Re: Crypto dongles to secure online transactions

2009-11-21 Thread Anne Lynn Wheeler

On 11/18/2009 12:22 PM, Bill Frantz wrote:

Perhaps I'm missing something, but my multiple banks will all accept my
signature when made with the same pen. Why wouldn't they not accept my
signature when made with the same, well protected, signing/user verifying
device. I might have to take it to the bank to give them its public key in
person, but that seems a minor inconvenience.

This kind of device sounds like a fine device for a banking industry
committee to specify.


we ran into that with doing chip that required to post-fab personalization ... 
eliminating lots of the costs thruout the whole infrastructure (eliminating 
personalization actually makes the delivered cost to the user less than the 
current infrastructure).

we then looked at the current institutional-centric paradigm ... where each institution 
wants to deliver token/card to user ... with having eliminating any personalization requirement ... 
then we claimed we could moved to a person-centric paradigm ... where a person could 
use the same token for potentially all their interactions ... having to wade through all the 
institutional arguments ... and addressing each one that stood in the way of moving from an 
institutional-centric paradigm to person-centric paradigm.

the smartcard industry was looking at possibly replacing every pin/password 
with a unique smartcard/dongle.

we claimed we do something like two orders magnitude reduction in fully-loaded 
costs by going to no personalization (and other things) ... and then another 
two orders magnitude reduction in number of tokens by transitioning from 
institutional-centric paradigm to person-centric paradigm (compared to proposed 
smartcard/dongle replacing every pin/password).

we then came up against that the bank marketing departments have taken 
advantage of the requirement for institutional personalization ... to put their 
brand and other stuff on every token. They started out saying they didn't want 
to do chip because it increased costs ... and when we showed we can come very 
close to driving costs to zero ... it turns out the marketing departments like 
the current infrastructure (despite the costs) ... because they feel it is 
important to have their brand on the token in each person's wallet.

There were various sorts of distractions/obfuscations ... like what happens if the 
only token fails ...
there is nothing that prevents a person from having two person-centric tokens 
(or personally choosing to have a their own unique token per institution). Then it was 
... what happens if the only token is stolen. It turns out that the standard threat is 
the wallet/purse is stolen with all the cards (eliminating any different between there 
being single token or multiple tokens).

In any case ... with a paradigm that has been in place for this long ... there 
are quite a large number of people that don't want to change ... some for no 
other real reason than its different ... for others they have leveraged current 
paradigm for things that couldn't have been independently justified on its own.

Early on uptake in various standards organization was good ... until some of 
the change implications started percolating thru the infrastructure. It was 
analogous to what we did with secure x9.59 financial transaction standard ... 
and then the implications of eliminating all the associated fraud started to 
sink in.

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Crypto dongles to secure online transactions

2009-11-16 Thread Anne Lynn Wheeler

On 11/10/2009 09:44 AM, Jerry Leichter wrote:

Not that this should block the use of devices like the ZTIC! They're
still much more secure than the alternatives. But it's important to keep
in mind the vulnerabilities we engineer *into* systems at the same time
we engineer others *out*.


vulnerabilities tend to be proportional to complexity.

we had been asked in to consult with small client/server startup that wanted to do payment transactions on 
their server ... they had also invented this technology called SSL applied to the process. The 
result is frequently called electronic commerce. The major use/purpose of that SSL in 
the world today is hiding the account number and other transaction details.

somewhat as a result, in the mid-90s we were invited to to participate in the x9a10 
financial standard working group which had been given the requirement to preserve 
the integrity of the financial infrastructure for all retail payments. Part of that 
was detailed threatvulnerability studies of different payment methods and 
environments. One of the biggest problems was vulnerability of leaking account 
number ... since it was trivial for crooks to use it for originating fraudulent 
transactions ... and at the same time required by millions of business processes 
around the world. So part of the resulting standard was slightly tweaking the 
paradigm and eliminating the account number (and transaction details) as a 
vulnerability (which then also eliminates the major use of SSL in the world today).

along the way, i also made semi-facetious comment that i would take a $500 
milspec item and aggressively cost reduce it by 2-3 orders of magnitude while 
making it more secure. Part of the effort effectively worked out getting it 
close to the EPC RFID technology process (items targeted at replacing UPC 
barcodes on grocery items at a few cents or less) w/o reducing security.

Basically it is all silicon ... which not only reduces a lot of after-FAB 
vulnerabilities ... but also eliminates the costs of a lot of the post-FAB 
processing steps (as silicon cost goes to zero, post-FAB processing costs 
started to dominate).

Along with it is the concept of security proportional to risk ... at the 
issuing authorization end of a transaction ... the security characteristics of 
the originating components can be evaluated ... in the case of the chip ... the 
security level of the chip can even be updated in real time as vulnerabilities 
are identified.
This can help decide like a when a few cent item might be needed to be replaced 
for higher value  transactions

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Crypto dongles to secure online transactions

2009-11-10 Thread Anne Lynn Wheeler

On 11/08/2009 02:07 AM, John Levine wrote:

At a meeting a few weeks ago I was talking to a guy from BITS, the
e-commerce part of the Financial Services Roundtable, about the way
that malware infected PCs break all banks' fancy multi-password logins
since no matter how complex the login process, a botted PC can wait
until you login, then send fake transactions during your legitimate
session.  This is apparently a big problem in Europe.

I told him about an approach to use a security dongle that puts the
display and confirmation outside the range of the malware, and
although I thought it was fairly obvious, he'd apparently never heard
it before.  When I said I'd been thinking about it for a while, he
asked if I could write it up so we could discuss it further.

So before I send it off, if people have a moment could you look at it
and tell me if I'm missing something egregiously obvious?  Tnx.

I've made it an entry in my blog at

http://weblog.johnlevine.com/Money/securetrans.html

Ignore the 2008 date, a temporary fake to keep it from showing up on
the home page and RSS feed.

R's,
John


deja vu 1999  this should be covered in enormous detail in the EU finread 
standards documents from the late 90s.

note that the EU finread standard from late 90s (over decade ago) was 
countermeasure to most every kind of PC compromise that you can think of. 
Basically it moved the end point out to independent hardware device with its 
own display and pin-pad. The transaction was still composed on the PC ... but 
had to be sent to the hardware finread device for approval/authentication. 
transaction to be approved/executed would be displayed on finread device for 
approval. It then required physical PIN entry to execute the approval process 
... typically assumed to be a digital signature ... which was returned to the 
PC.

compromised PC could still do a denial of service ... but the independent finread 
device effectively moved the end-point from the PC out to the finread. the 
independent display  pin-pad ... was countermeasures to various kinds of 
exploits ... including

* keylogging ... trojan horse or other could execute transactions w/o users 
actual knowledge

* is the transaction that the user sees the actual transaction being executed

bad design might have used the finread for session authentication in lieu of 
separately authentication/approval for every transaction (which would allow 
trojans on compromised pcs to execute fraudulent transactions within the 
boundaries of the session.

infrastructure would still be vulnerable to various kinds of social engineering 
... convincing end-user to execute valid transactions for the benefit of the 
attacker.

There was some conjecture (again more than decade ago) that if finread 
deployment eliminated all the other kinds of compromises ... that user 
education programs could purely concentrate on social engineering exploits 
(sort of like the stuff for little kids to have nothing to do with strangers).

EU finread program got caught up in the disastrous deployment of serial-port 
card acceptor device at the start of the decade (many versions had the 
appearance of card acceptor device with its own independent display and pin-pad 
... slightly akin to small POS terminals that might appear at point-of-sale). 
The disastrous serial-port acceptor device deployment resulted in rapidly 
spreading opinion in the financial industry that smartcards and card readers 
weren't practical in the consumer market ... resulting in nearly all such 
programs quickly evaporating w/o hardly a trace.

As i've mentioned before ... it wasn't actually a problem with smartcards 
and/or card readers  but with the serial-port interface. In the 1995 
time-frame there were a number of presentations about moving the dial-up home 
banking programs to the internet ... in large part motivated by the significant 
customer support costs associated with supporting serial-port modems (one such 
bank program claimed to have a library of over 60 serial port modem software 
drivers to try and cover some reasonable set of their customers. Problems with 
the whole serial-port gorp was also big motivator behind development of USB.

In any case, i've commented before about the financial industry institutional 
knowledge and experience apparently rapidly evaporated between the migration of 
dial-up home banking (migration to the internet) and 2000. A partial/possible 
explanation might be that the vendor, knowing that everything was moving to 
USB, saw a really great chance to unload their stock of obsolete serial-port 
devices on a client that didn't really know what they were doing.

lots of past EU finread standard posts:
http://www.garlic.com/~lynn/subintegrity.html#finread

random trivia ... i was at an eu finread standard meeting in brussels not long 
before the whole thing with serial-port resulted in all such programs imploding 
(even those not using serial-port ... radiation from the event 

Re: Client Certificate UI for Chrome? -- OT anonymous-transaction

2009-08-21 Thread Anne Lynn Wheeler

On 08/20/09 00:11, Ray Dillinger wrote:

No.  This juvenile fantasy is complete and utter nonsense, and
I've heard people repeating it to each other far too often.  If
you repeat it to each other too often you run the risk of starting
to believe it, and it will only get you in trouble.  This is a
world that has not just cryptographic protocols but also laws
and rules and a society into which those protocols must fit.  That
stuff doesn't all go away just because some fantasy-world
conception of the future of commerce as unlinkable anonymous
transactions says it should.


most of the financial industry digital certificate specifications
were relying party only digital  certificates ... effectively only
containing an account number ... because of privacy (both in us and
europe) and liability issues. some of this was also about the time
that EU-DPD made statements that electronic retail transactions
should be w/o names (i.e. remove person names from payment cards
... also a form of relying party only instrument).

this somewhat side-stepped whether it was linkable or not ...
since it then was back at the financial institution whether
the account number was linked to a person or anonymous ... but
did meet privacy requirements for retail payments  depending
on gov.  financial institution with regard to any possible
know your customer mandates ... a court order to the
financial institution  had the potential of revealing any linkage

There were a couple issues:

1) even as a relying-party-only digital certificate ... the digital
certificate gorp resulted on the order of 100 times payload bloat for typical
payment transaction payload size. there were two approaches a) strip the
digital certificate off the payment transaction as early as possible
to minimize the onerous payload penalty; b) financial standards looked
at doing compressed relying-party-only digital certificates ... possibly
getting the payload bloat down to only a factor of ten times (instead of
one hundred times).

2) it was trivial to show that the issuing financial institution
already had a superset of information carried in the relying-party-only
digital certificate ... so it was redundant and superfluous to repeatedly
send such a digital certificate back to the issuing financial institution
appended to every payment transactions (completely redundant and superfluous
was separate issue from representing factor of 100 times payload bloat).

so there were two possible solutions to the enormous payload bloat

a) just digital sign the transaction and not bother to append
the redundant and superfluous relying party only certificate

b) the standards work on compression included eliminating fields
that the issuing financial institution already possessed ... since
it was possible to demonstrate that the issuing financial institution
had a superset of all information in a relying-party-only digital
certificate ... it was possible to compress the size of the
digital certificate to zero bytes. then it was possible to mandate
that zero byte digital certificates be appended to every payment
transaction (also addressing the enormous payload bloat problem).

the x9.59 financial transaction standard ... some refs
http://www.garlic.com/~lynn/x959.html#x959

just specified requirement for every payment transaction
to be authenticated ... and didn't really care whether there was
no digital certificate appended ... or whether it was
mandated that zero-byte digital certificates were appended.

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Client Certificate UI for Chrome?

2009-08-06 Thread Anne Lynn Wheeler

On 08/06/09 07:33, James A. Donald wrote:

The fundamental problem with certificates is getting them.


digital certificate design point supposedly was the dial-up email of the early 
80s,
dial-up, exchange email, hang-up ... and then faced with how to deal with first
time email from complete stranger. basically electronic analog for letters of
credit/introduction from sailing ship days.

in the 90s, because of numerous privacy and liability issues ... there
was some number of relying-party only certificates; individual registered
their public key with the institution, institution then created a digital
certificate with the public key, archived it, and returned a copy to the
individual. the individual, in communication with the institution would
digitally sign the communication and then append the digital certificate.
However, it was trivial to prove that the institution/relying-party already
had a copy of the information ... and the appended digital certificate
was redundant and superfluous. misc. past posts discussion relying-party only
digital certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

furthermore, major foreys into this sector were by financial institutions
for the purpose of payment transactions. a complicating factor ... besides
the digital certificates being redundant and superfluous ... they added
a 100 times payload size bloat to the typical payment transactions. misc.
past posts
http://www.garlic.com/~lynn/subpubkey.html#bloat

there was a financial standards effort that looked at possibly doing
compressed digital certificates (trying to achieve only ten times bloat)
... eliminating redundant fields and information already in the possession
of the individual's financial institution. we showed that the individual's
financial institution already had superset of the information in the
digital certificate ... so it was possible to compress digital certificates
to zero bytes ... and then mandate that financial transactions would always
have zero-byte certificates appended (as opposed to no appended digital
certificate).

Something similar was demonstrated for RADIUS and Kerberos ... registering
a public key in lieu of password ... some past references
http://www.garlic.com/~lynn/subpubkey.html#radius
and
http://www.garlic.com/~lynn/subpubkey.html#kerberos

and also something similar for registering public key with domain
name registration with domain name infrastructure ... for use in
lieu of SSL digital certificates
http://www.garlic.com/~lynn/subpubkey.html#catch22

that left institutions and relying party with no-value business processes
as digital certificate opportunities ... i.e. no-value transactions where
the relying party couldn't justify the cost of their own entity repository
and/or justify the cost of doing an online transactions to obtain such entity
information ... and of course ... the original design point, the offline
email scenario with first time communication with complete strangers.

One of the problems with no-value market segment is that it is hard for
institutions and individuals to justify paying for things without
any value ... and therefor it is hard to find entities looking
at selling things for nothing.

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: password safes for mac

2009-07-01 Thread Anne Lynn Wheeler

On 07/01/2009 02:10 PM, Nicolas Williams wrote:

I should add that a hardware token/smartcard, would be even better, but
the same issue arises: keep it logged in, or prompt for the PIN every
time it's needed?  If you keep it logged in then an attacker who
compromises the system will get to use the token, which I bet in
practice is only moderately less bad than compromising the keys
outright.


Nominally, hardware token is something you have authentication. In many 
implementations,
business rules are added to the chip for stuff like business requirements for
multi-factor authentication (like in conjunction with PIN). The resulting
situation is business rule/environment specific.

In the late 90s, there was work on EU FINREAD standard for external trusted
card-acceptor device ... that had trusted pin-entry and trusted display. The
objective was countermeasure to lots of well known compromises of PCs (including
keylogger ... implying that compromised PC could operate an external hardware 
token,
even if PIN was required per transaction).

A lot of this evaporated in the early part of this decade in the wake  of with
various troubles associated with hardware tokens.

As an aside ... one of the things we did in the AADS patent portfolio was
to remove business rules from the hardware token ... as part of
enabling person centric operation (i.e. the same token might be
used for lots of different environments ... as opposed to having
hardware token for every unique business environment).

An AADS hardware token can support both single-factor as well as multi-factor
authentication operation ... but it is up to the business application 
interacting
with the hardware token to indicate the amount of authentication  integrity
(some assumption about security proportional to risk ... for instance,
whether or not PIN might be required for every operation, or at all).

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Solving password problems one at a time, Re: The password-reset paradox

2009-05-21 Thread Anne Lynn Wheeler

On 05/09/09 07:33, Jerry Leichter wrote:

I had a discussion with a guy at a company that was proposing to create
secure credit cards by embedding a chip in the card and replacing some
number of digits with an LCD display. The card would generate a unique
card number for you when needed. They actually had the technology
working - the card was pretty much indistinguishable from any other. (Of
course, how rugged it would be in typical environments is another
question - but they claimed they had a solution.)



Deloitte staff trial Visa card with built in OTP generator for IT access control
http://www.finextra.com/fullstory.asp?id=20019



--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Solving password problems one at a time, Re: The password-reset paradox

2009-05-09 Thread Anne Lynn Wheeler

On 05/09/09 07:33, Jerry Leichter wrote:

On May 8, 2009, at 3:39 PM, Ian G wrote:

The difficulty with client certs is that I need them to also work on my
laptop. And my other laptop. And my phone.

So, how do I get hold of them when I'm on the road?


Good point. The difficulty with my passwords is that I have so many
that are so long that I can only manage them on my laptop, and have to
carry my laptop with me ...

We can imagine all sorts of techie solutions to this, but it does
appear that we are in a bit of a grey zone with auth at the moment,
and the full solution might take a while to emerge. Try them all?

This is part of a broader UI issue.

I had a discussion with a guy at a company that was proposing to create
secure credit cards by embedding a chip in the card and replacing some
number of digits with an LCD display. The card would generate a unique
card number for you when needed. They actually had the technology
working - the card was pretty much indistinguishable from any other. (Of
course, how rugged it would be in typical environments is another
question - but they claimed they had a solution.)

I pointed out that my wife knows one of her CC numbers by heart. The
regularly quotes it, both on phone calls and to web forms. The card
itself is buried in a thick wallet, which is buried in her pocketbook,
which is somewhere in the house - likely not near the phone or the
computer.

Hell, one of the nice things about on-line shopping is that I can do it
in my bathrobe - except that I *don't* know my CC by heart, so in fact I
tend to put off buying until later when I have my wallet with me. (This
does save me money)

When I'm in a store, I'm used to having to have my CC with me, because I
always had to have the wallet with money anyway. At home, it's a whole
different story. In any case, merchants are trying to make the in-store
experience as simple as possible, pushing for things like RFID credit
cards and even fingerprint recognition.

So many people would see these safer cards as a big step backwards in
usability. Why would they want such a thing? The card companies are
trying to sell safety, but in the US, where your liability is at most
$50 if your CC number is stolen (and where in practice it's $0), the
only cost you as an individual bear is the inconvenience of replacing a
card. Because replacements for security problems have gotten so common,
the CC companies have streamlined the process. It's really no big deal.
I've had CC numbers stolen a couple of times (by means unknown);
recently, two of my CC's were replaced by the companies based on some
information known only to them. In every case, the process was very
quick and painless. Hell, these days even on-line continuing charges
often update to the new number automatically (though I've learned to
keep track of those and check).

The person arguing for this claimed that CC companies could offer a
discount for users of the secure cards. But if you look at actual loss
rates - how much could you offer? (I'd guess it's about the same as
Discover offers: About a 1.5% rebate on most purchases. Not enough to
let Discover steal customers from Visa and MC. Given all the other
charges - and the absurdly high interest rates - on cards, anything like
this gets lost in the noise.)

Security that depends on people changing their habits in a way that is
inconvenient to them ... won't happen (unless you're in an environment
where you can *force* such changes).
-- Jerry


at least the initial introduction of one-time-account number displays
had a problem because they couldn't meet the flexing specification
(like cards in mens wallet and getting sat on).

note that there has been big push to signature debit (similar interchange
fees and fraud as signature credit) with 15 times the fraud of PIN-debit
(which has significantly lower interchange fees compared to signature debit)
reference
http://www.digitaltransactions.net/newsstory.cfm?newsid=73
mentioned in this post from 2006
http://www.garlic.com/~lynn/2006e.html#21

there has been some articles about unsafe cards being a profit item
for financial institutions ... since they charge merchants a significantly
higher interchange fee. there have been references that there can be
as much as a order of magnitude difference in fees between unsafer transaction
fees and safer transaction... with unsafe transaction fees
contributing significantly to reports that payment fees have represented
as much as 40% of bottom line for US consumer financial institutions
(an order of magnitude reduction would be a big hit). part of thread
on this subject in this mailing list from two years ago
http://www.garlic.com/~lynn/aadsm27.htm#31
http://www.garlic.com/~lynn/aadsm27.htm#32
http://www.garlic.com/~lynn/aadsm27.htm#33
http://www.garlic.com/~lynn/aadsm27.htm#34
http://www.garlic.com/~lynn/aadsm27.htm#35
http://www.garlic.com/~lynn/aadsm27.htm#37
http://www.garlic.com/~lynn/aadsm27.htm#38

Re: Has any public CA ever had their certificate revoked?

2009-05-05 Thread Anne Lynn Wheeler

On 05/05/09 14:01, Thierry Moreau wrote:

Before the collapse of the .com market in year 2000, there were
grandiose views of global PKIs, even with support by digital signature
laws.

Actually, it turned out that CA liability avoidance was the golden rule
at the law and business model abstraction level. Bradford Biddle
published a couple of articles on this topic, e.g. in the San Diego Law
Review, Vol 34, No 3.

The main lesson (validated after the PKI re-birth post-2002) is that no
entity will ever position itself as a commercially viable global CA
unless totally devoid of liability towards relying parties.

Thus no punishment is conceivable beyond the Peter's opinions (they are
protected by Freedom of speech at least). That was predicted by the Brad
Biddle analysis 12 years ago.


we had been brought in to help word-smith the cal. state electronic signature law. there was some legal 
types who very clearly differentiated what was required for something to be considered human 
signature (implication that something has been read, understood, agrees, approves, /or 
authorizes) and PKI digital signatures used for authentication.

we've periodically commented that there may be some cognitive dissonance because both 
terms contain the word signature.

slightly related pontification
http://www.garlic.com/~lynn/2009g.html#48

regarding this recent article mentioning SSL

Inventor: SSL security woes are really the fault of browser design
http://www.fiercecio.com/techwatch/story/inventor-ssl-security-woes-really-fault-browser-design/2009-05-05

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Certificates turn 30, X.509 turns 20, no-one notices

2008-11-27 Thread Anne Lynn Wheeler

On 11/27/08 05:13, Nicholas Bohm wrote:

I've never been quite sure whether Public qualifies Key or
Infrastructure - this may make a difference to what you count as a PKI.

SWIFT (interbank messaging), BOLERO (bills of lading) and CREST (dealing
in dematerialised stocks and shares) all use public key cryptography, I
believe, and have all been reasonably successful; but they are all
closed systems where each of the participants believes that it and the
others can stand the risk of contractually-imposed non-repudiation rules
(or they used to believe it, anyway).

But what these examples illustrate, by the lack of open comparables,
is the very limited utility of the technology.


in the past capitalization referred to CAs making the rounds of
wallstreet with $20B/annum business case (i.e. approx. $100/annum per
adult in the US).

The lower case public key met that an entity could make
their public key available ... as countermeasure to the shortcomings
of shared-secret (password/PIN) paradigm ... where a unique shared-secret
was required for every unique security domain (the current scenario where
scores or hundreds of unique shared-secrets have to be managed).

going from lower-case ... where an entity could share the same
public key with large number of different entities, to upper-case,
was the scenario justifying the $20B/annum business case.

sometimes the issue isn't whether the public key is open/closed ... the
issue is whether the business liability is between the parties
involved ... or should random, unrelated participants also get
involved in the business processes.

there have been some attempts at obfuscation ... attempting
to confuse the boundaries between the authentication technology
and the parties involved in business processes liability

i was at annual acm sigmod (aka database) conference in 91 (92?)
and during one of the sessions, somebody asked a question regarding
what was all this X.5xx stuff going on ... and the reply was that
a bunch of networking engineers were trying to re-invent 1960s
database technology.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Secure64 Develops First Automated DNSSEC Signing Application to Help Secure the Internet Worldwide

2008-07-30 Thread Anne Lynn Wheeler
Secure64 Develops First Automated DNSSEC Signing Application to Help 
Secure the Internet Worldwide

http://www.businesswire.com/news/google/20080730005428/en

from above:

Secure64 Software Corporation has developed a product that
dramatically simplifies the implementation and management of
DNSSEC. Secure64 DNS Signer™ is the first and only product that
addresses each of the obstacles that have slowed the widespread
deployment of DNSSEC zone signing, including the need for simplicity,
security, auditability and scalability. While recent patching efforts
have mitigated the impact of the cache poisoning vulnerability
identified by Dan Kaminsky and widely reported by the media,
deployment of DNSSEC is widely regarded as the only viable long-term
solution to securing the Domain Name System (DNS).

... snip ...

One of the people behind Itanium design ... was one of the Secure64
founders ... somewhat as part of demonstrating what could be done with
features that had been included in Itanium chip architecture. I've
noted before that they had been heavily involved in earlier RISC chip
efforts ... including original 801 risc chip. misc. past posts
mentioning 801, risc, romp, rios, somerset, fort knox, power/pc, etc
http://www.garlic.com/~lynn/subtopic.html#801

--
40+yrs virtualization experience (since Jan68), online at home since Mar70

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The PKC-only application security model ...

2008-07-24 Thread Anne Lynn Wheeler

Thierry Moreau wrote:
Anne  Lynn Wheeler wrote about various flavors of certificateless 
public key operation in various standards, notably in the financial 
industry.


Thanks for reporting those.

No doubt that certificateless public key operation is neither new nor 
absence from today's scene.


The document I published on my web site today is focused on fielding 
certificateless public operations with the TLS protocol which does not 
support client public keys without certificates - hence the 
meaningless security certificate. Nothing fancy in this technique, 
just a small contribution with the hope to facilitate the use of 
client-side PKC.


this post references scenario for replacing the SSL server domain name 
certificates with a certificate-less public key infrastructure
http://www.garlic.com/~lynn/2008k.html#49 The PKC-only application 
security model


the first reply
http://www.garlic.com/~lynn/2008k.html#48 The PKC-only application 
security model


mentions certificate-less X9.59 (financial transaction), 
certificate-less KERBEROS (large number of infrastructure and 
application authentication operation) and certificate-less RADIUS 
(possibly dominant client authentication infrastructure in the world 
today used by lots of ISP, corporate intranets, webhosting operations, etc).


RADIUS provides a generalized authentication, authorization, and 
accounting infrastructure ... where AAA specifics can be specified on an 
account or client basis (i.e. including being able to easily 
accomodating both password and public key concurrently).

http://www.garlic.com/~lynn/subpubkey.html#radius

There are even RADIUS plug-ins for webservers for doing webserver 
client authentication.


A combination of replacing SSL server domain name certificates with 
certificate-less server operation and
and using certifcate-less RADIUS (client) authentication ... covers 
mutual (client  server) operation.


RADIUS references from our rfc index:
http://www.garlic.com/~lynn/rfcietff.htm

click on Term (term-RFC#) field and then click on RADIUS (in the 
Acronym fastpath):


Remote authentication dial in user service (RADIUS)
see also authentication , network access server , network services
5176 5090 5080 5030 4849 4818 4679 4675 4673 4672 4671 4670 4669 4668
4603 4590 4372 4014 3580 3579 3576 3575 3162 2882 2869 2868 2867 2866
2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058



clicking on any of the RFC numbers, retrieves the RFC summary in the 
lower frame. Clicking on the .txt=nnn field (in a RFC summary) 
retrieves the actual RFC.



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The PKC-only application security model ...

2008-07-24 Thread Anne Lynn Wheeler

Thierry Moreau wrote:
In draft-ietf-sip-dtls-srtp-framework, the detailed scheme uses 
self-signed certificates created by client end-entities themselves. 
The basic idea is identical. At the detailed level in my document, the 
client end-entity auto-issues a security certificate with a 
breached CA private key.


In the TLS Certificate request message, a list of CA distinguished 
names is provided to the end entity. Referring to a breached CA 
public key is an invitation to submit a meaningless end-entity 
certificate, making the detailed scheme more plain with respect to 
TLS options (i.e. an empty list in a certificate request message could 
be a not so well supported mode in TLS software implementations).


So, maybe the reference to the notion of self-signed EE certificates 
in draft-ietf-sip-dtls-srtp-framework could be replaced by 
meaningless EE certificates (or something else), which would include 
both self-signed or auto-issued. In such a case, the RFC publication 
for my document would become more pressing.


A related discussion occurred on the IETK PKIX mailing list in June 
2008 under the subject RFC 5280 Question.



re:
http://www.garlic.com/~lynn/2008k.html#48 The PKC-only application 
security model
http://www.garlic.com/~lynn/2008k.html#49 The PKC-only application 
security model
http://www.garlic.com/~lynn/2008k.html#51 The PKC-only application 
security model


another approach that X9 financial standard organization took to attempt 
the enormous
digital certificate bloat was standards effort for compressed digital 
signature ...
possibly reducing  100-times bloat to possibly only 5 to 10 times bloat. 
There
was some conjecture that such lightweight digital certificates might 
also find

place in wireless applications.

part of compression effort was to recognize that the server already had much
of the information was exactly the same in every certificate and/or the 
server

already possessed.

I raised the issue (rather than harping on the theme that digital 
certificates
being redundant and superfluous ... besides 100 times bloat)  that 
(for all the
situations they were looking at) the server already had all the 
information in a digital
certificate. Therefor, it would be possible to define a new class of 
zero byte
digital certificates that would be appended to every digitally signed 
transaction.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The PKC-only application security model ...

2008-07-23 Thread Anne Lynn Wheeler

Thierry Moreau wrote:
A)The big picture refers to the PKC-only application security 
scheme, in which client-server applications may be secured with 
client-side public key pairs, but *no trusted certification authority* 
is involved (server operators are expected to maintain a trusted 
database of their clients' public keys).
original PK-init (public key) draft for Kerberos was (only) 
certificateless public key operation ...
i.e. kerberos server operators maintaining trusted database of their 
clients' public keys (in
lieu of passwords) ... PKI/certificate mode of operation was eventually 
added to the specification.

lots of past posts about  certificateless public key kerberos
http://www.garlic.com/~lynn/subpubkey.html#kerberos

similar implementation was done for RADIUS
http://www.garlic.com/~lynn/subpubkey.html#radius

general posts about certificateless (sometimes naked) public key
http://www.garlic.com/~lynn/subpubkey.html#certless

X9.59 is financial transaction standard also using certificateless 
public key operation

http://www.garlic.com/~lynn/x959.html#x959

part of the issue was that in the mid-90s, the x9a10 financial standard 
working group
had been given the requirement to preserve the integrity of the 
financial infrastructure
for all retail payments. One of the issues for x9.59 was that it had to 
be lightweight enough
to operate in existing infrastructures. Some of the certificate-oriented 
payment transaction
standards from the period resulted in factor of 100 times (two orders of 
magnitude) payload
(i.e. certificate payload overhead could be 100 times larger than basic 
payment transaction)
and processing (i.e. certificate processing overhead could be 100 times 
larger than basic

payment transaction) bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat

general discussions of the account authority public key model (as 
contrast to

certification authority public key model)
http://www.garlic.com/~lynn/x959.html#aads

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: WoW security: now better than most banks.

2008-07-05 Thread Anne Lynn Wheeler

Perry E. Metzger wrote:

My bank doesn't provide any sort of authentication for logging in to
bank accounts other than passwords. However, Blizzard now allows you
to get a one time password keychain frob to log in to your World of
Warcraft account.


   


post in thread here a yr ago (1jul07) about financial institutions 
attempting some
(disastrous) deployments in the 99/00 time-frame ... and then instead of 
taking
blame for deployment problems ... there was quickly spreading opinion 
that hardware

tokens weren't practical in the consumer market place
http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game

as noted in another post ... the disastrous failures were somewhat a case of
institutional knowledge not permeating different part of the organizations.

banking conferences in the mid-90s were attributing the existing online 
banking
migration to the internet in large part motivated by significant 
customer support

problems with serial port modems (mostly with the serial port part).
http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game

that even if a little bit of the experience form the earlier online banking
programs had carried over into the later hardware token deployments ...
much of the deployment problems could have been averted.

In any case, the claim could be made that the industry is still attempting
to recover from those disasters.

a couple other posts on the same subject in other threads:
http://www.garlic.com/~lynn/2007n.html#65 Poll: oldest computer thing 
you still use
http://www.garlic.com/~lynn/2007t.html#22 'Man in the browser' is new 
threat to online banking

http://www.garlic.com/~lynn/2007u.html#11 Public Computers

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The wisdom of the ill informed

2008-06-30 Thread Anne Lynn Wheeler

James A. Donald wrote:
Committees of experts regularly get cryptography wrong - consider, for 
example the Wifi debacle.  Each wifi release contains classic and 
infamous errors - for example WPA-Personal is subject to offline 
dictionary attack.


One would have thought that after the first disaster they would have 
hired someone who could do it right, but as Ian long ago pointed out, 
in the market for silver bullets, they are unable to tell who can do 
it right.  The only people who know who the real experts are, are the 
real experts.   If you knew who to hire, you could do it yourself, and 
probably should do it yourself.  So they hire expert salesmen, not 
cryptography experts.
the other scenario was that the cryptography part was done from such a 
myopic standpoint ... that they failed to consider the end-to-end 
infrastructure.


I've repeatedly heard excuses that the cryptographers in the wifi 
debacle believed that they could only design a solution based on 
significant hardware restrictions/constraints. part of what i observed 
... by the time any of them shipped ... the hardware 
restrictions/constraints no longer existed . the other thing that i 
observed was that with relatively trivial knowledge about chips ... it 
was possible to come up with an integrated solution that incorporated 
both the necessary hardware and the necessary cryptography  ...  there 
has got to be some analogy here someplace about the blind trying to 
describe an elephant; in addition to the point solution analogy, 
failing to take in the overall infrastructure.


i've repeatedly claimed that we did that in the AADS chip strawman solution
http://www.garlic.com/~lynn/x959.html#aads

that including addressing all the issues that showed up in scenarios 
like with the yes cards

http://www.garlic.com/~lynn/subintegrity.html#yescards

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Own a piece of the crypto wars

2008-06-17 Thread Anne Lynn Wheeler

archeological email about proposal for doing pgp-like public key
(from 1981):
http://www.garlic.com/~lynn/2006w.html#email810515

the internal network was larger than the arpanet/internet from
just about the beginning until sometime summer of '85. corporate
guidelines had become that all links/transmission leaving corporate
facilities were required to be encrypted. in the '80s this met
lots of link encryptors (in the mid-80s, there was claim that
internal network had over half of all the link encryptors in the world).

a major crypto problem was with just about every link that crossed any
national boundary created problems with both national gov. links
within national boundaries would usually get away with argument
that it was purely internal communication within the same
corporate entity. then there was all sorts of resistance encountered
attempting to apply that argument to links that cross national
boundary (from just about every national entity).

For other archeological lore ... old posting with new networking
activity from 1983
http://www.garlic.com/2006k.html#8

above posting includes listing of locations (around the world)
that had one or more new network links (on the internal
network) added sometime during 1983 (large precentage
involved connections requiring link encryptors).

more recent post
http://www.garlic.com/~lynn/2008h.html#87

mentioning coming to the realization (in the 80s) that there
were three kinds of crypto.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Ransomware

2008-06-09 Thread Anne Lynn Wheeler

John Ioannidis wrote:
This is no different than suffering a disk crash.  That's what backups 
are for.




At Jim Gray's tribute on the 31st, Bruce Lindsay gave a talk about Jim's
formalization of transaction processing enabled online transactions ... i.e.
needed trust in the integrity of integrity of transaction as prerequisite
to move from manual/paper processes.

In the early 90s, when glasshouse and mainframes seeing significant
downturn in their use ... with lots of stuff moving off to PCs, there
was a study that half of the companies that had a disk failure involving
(business) data that wasn't backed up ... filed for bankruptcy within
30 days. The issue was that glasshouse tended to have all sorts
of business processes to backup business critical data. Disk failures
that lost stuff like billing data had significant impact
on cash flow (there was case of large telco that had
bug in its nightly backup and when the disk crashed with customer
billing data ... they found that there didn't have valid backups).

Something similar also showed up in the Key Escrow meetings in the
mid-90s with regard to business data that was normally kept in encrypted
form ... i.e. would require replicated key backup/storage in order to
retrieve data (countermeasure to single point of failure). part of the
downfall of key escrow was that it seem to want all keys ... not just
infrastructure where business needed to have replicated its own
keys.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Can we copy trust?

2008-06-03 Thread Anne Lynn Wheeler

Bill Frantz wrote:

really used for strangers. For people we know, recognition and
memory are more compelling ways of trusting.

We can use this recognition and memory in the online world as well.
SSH automatically recognizes previously used hosts. Programs such
as the Pet Names Toolhttp://www.waterken.com/user/PetnameTool/
recognize public keys used by web sites, and provide us with a
human-recognizable name so we can remember our previous
interactions with that web site. Once we can securely recognize a
site, we can form our own trust decisions, without the necessity of
involving third parties.
   


that was one of the business case problems early in SSL for
electronic commerce ... namely majority of ecommerce was
with repeat sites ... while design point of digital certificates
is for first time communication between strangers.

the other factor that bounded what merchants would pay
was liability in electronic commerce ... there were already
paying significant interchange fees as part of protecting
the consumer. certification authorities weren't looking
at taking on any of that aspect.

the combination has been pushing digital certificates
into the no-value market segment ... which, in turn,
further limits what would could be charged for.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: not crypto, but fraud detection + additional

2008-05-27 Thread Anne Lynn Wheeler

Allen wrote:
I don't know what the policy is in Ireland, but here in the USA there 
is no stop loss on debit cards so the banks are not obligated to make 
good on fraudulent withdrawals. I believe that most have out of fear 
of bad PR, but you have to fight for it if it is just a few that it 
happens to. If this happens too much then people might stop using 
debit cards. I have advised my mother, 87, to not use them as she is 
getting a little slow on the uptake and might miss something like this 
if it happened to her.


Now to show how screwy the system is, I was shopping the other day and 
the power went off in the grocery store I was at. They had backup 
power so they were able to check out people; however, they couldn't 
use debit cards, except Well, the screwy thing was if you entered 
the charge at terminal as a credit card, even when it was only a debit 
card, it would accept it. I checked my bank, and sure enough the 
charge showed as a POS charge!


I think the logic is a little screwy and might be able to be exploited 
though I'm not sure how at the moment.
in theory signature debit (i.e. debit transaction w/o PIN) and credit 
could both work ...  since they both go thru the same way.


pin-debit goes thru in real time and the merchant has assurance that the 
transaction has been approved (and pin authenticated).  as a result, the 
interchange fee is much lower ... because the related risk/fraud is 
presumed to be much lower.


signature debit and credit basically go thru the network the very same 
way. the machine (either the actual POS terminal or a store controller) 
remembers all the transactions and there is periodic batch settlement 
(end of shift, or end of day). Settled transaction may or may not have a 
separate, associated real time authorization transaction.


The merchant pays extra charge for each real time authorization 
transaction (which tend to be credit card specific regarding whether the 
account is active and the new transaction is within the card's credit 
limit or open to buy).


the associated interchange fee is lower on transactions with real 
time authorizations (presumably transactions with real time 
authorizations tend to have lower risk/fraud). However, transactions 
may also be settled w/o an associated real time authorization (which 
will have a higher interchange fee since there is presumption of higher 
risk/fraud). there are some old merchant small fraud stories ... where 
the merchant claimed in the settlement transaction to have a separate 
real time authorization ... when there wasn't one (they got both the 
lower interchange fee w/o actually having to pay for a real-time 
authorization transaction ... this was before some financial 
institutions had the ability to reconcile the information).


All have associated risk/fraud ... one of the tricks is for the 
financial institution to appropriately adjust the interchange fee to 
cover the financial institutions associated risk.


There has been recent congressional hearings, EU anti-trust actions and 
merchant complaints that the financial institutions have adjusted the 
interchange fees way over what is needed to cover the associated risk. 
There were snide articles that financial institutions are making 
significant profits off of the risk adjusted interchange fees. 2-3 yrs 
ago supposedly something like 40percent of US financial institution 
bottom line was coming from these (risk adjusted) interchange fees ... 
and for many retailers it represented their single largest expense.


this is been highlighted in the significant expense going into TV spots 
to promote signature debit  since the interchange fee and 
especially the profit is significantly higher (vis-a-vis pin-debit).


some of this was discussed in the bank fraud blame game thread that 
went on in this mailing list

last june, july ... my posts archived here.
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#37 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The 
bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The 
bank fraud blame game

http://www.garlic.com/~lynn/aadsm27.htm#41 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#42 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#43 a fraud is a sale, Re: The 
bank fraud blame game


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


not crypto, but fraud detection

2008-05-26 Thread Anne Lynn Wheeler


*Irish Bank Debit Card Skimmers Net €1m*
http://www.epaynews.com/index.cgi?survey=ref=browsef=viewid=121179135013743148197block=

from above:

Most of the withdrawals took place at the end of April and early May 
2008. Many of the victims contacted their banks to notify them of the 
withdrawals, as the banks’ fraud detection systems had failed to spot 
the suspicious activity.


... snip ...

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


SSL use

2008-05-02 Thread Anne Lynn Wheeler
I've periodically posted that certain assumptions were made about safe 
SSL deployment for electronic commerce that were almost immediately 
invalidated.


The original assumptions assumed that the enduser knew the binding 
between the webserve that they thot they were talking to and the 
corresponding URL ... which they would then type into the browser. Then 
SSL would provide the assurance that the webserver that was actually 
being talked to corresponding URL. The two pieces together than provided 
that the enduser thot they were talking to was, in fact, the webserve 
that they were talking to.


Almost immediately merchants invalidated the assumptions when they found 
that SSL represeted 4-5 times degradation in webserver thruput ... and 
dropped back to just using SSL for payment/checkout portion of the 
electronic commerce. Now a web button was clicked, providing an URL. 
Now the only thing going on was that SSL would verify that whatever 
webserver, the webserver claimed to be, was the webserver it claimed.


This button clicking operation invalidated the original safety 
assumptions regarding the use of SSL for electronic commerce. The URL 
supplied by the button can be anything. Some amount of 3rd party payment 
processing outsources appeared to have taken advantage of this feature. 
A lot of phishing email also takes advantage of the paradigm also.


I was recently invited to resister at a website with a non-US country 
domain. My registration would not even closely work since it appeared to 
require IE ... and since I don't have any windows machines ... I also 
don't have any IE browser. However in the process I thot I would poke 
around a little.


I prefixed the URL with https (instead) of http. This got me a warning 
that the certificate was not for the indicated domain. When i looked at 
the certificate, it came from a certification authority that my browser 
recognized but was for a .com domain associated with some NIGERIAN 
payment processing operation.
I then check the ip-address of the original (non-US country) domain and 
found it mapped to some US-based webhosting company. I then check the 
ip-address of the NIGERIAN payment processing operation and found it 
mapped to some other US-based webhosting company.


I can only speculate that the first webhosting operation has some sort 
of default configuration for electronic commerce ... where SSL gets 
mapped to payment processing operation of this NIGERIAN payment 
processing operation.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Designing and implementing malicious hardware

2008-04-26 Thread Anne Lynn Wheeler

Leichter, Jerry wrote:

While analysis of the actual silicon will clearly have to be part of
any solution, it's going to be much harder than that:

1.  Critical circuitry will likely be tamper-resistant.
Tamper-resistance techniques make it hard to see what's
there, too.  So, paradoxically, the very mechanisms used
to protect circuitry against one attack make it more
vulnerable to another.  What this highlights, perhaps,
is the need for transparent tamper-resistance techniques,
which prevent tampering but don't interfere with inspec-
tion.
   


traditional approach is to make the compromise more expensive that any
reasonable expectation of benefit (security proportional to risk).

helping bracket expected fraud ROI is an infrastructure that can (quickly)
invalidate (identified) compromised units. there has been some issues
with these kinds of infrastructures since they have also been identified
with being able to support DRM ( other kinds of anti-piracy) efforts.

disclaimer: we actually have done some number of patents (that are 
assigned)

in this area
http://www.garlic.com/~lynn/aadssummary.htm

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-10 Thread Anne Lynn Wheeler

re:
http://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL

so lots of the AADS
http://www.garlic.com/~lynn/x959.html#aads

scenarios are that every place a password might appear, have
a public key instead.

for various of the cookie authentication operations ... also
think kerberos tickets. recent reference
http://www.garlic.com/~lynn/2008c.html#31 Kerberized authorization service

part of the scenario for cookie/ticket encryption ... involving
servers, is brute force attack on the server secret key. the cookie
instead of all encrypted data ... has some sort of client registration
value ... analogous to an account number or userid. the cookie caries the
registration value followed by the server encrypted data.  the
encryption part uses a derived key ... formed by combination of the
server's secret key and the client's registration value. these derived
key scenarios are also found in transit system operation (both
magstripe and memory chip) as well as financial transactions.

the issue then is initial registration ... the part where the user
chooses their userid (and/or the client registration value is
otherwise selected) and supplies a password (but in this case a public
key). m'soft and others have been using CAPTCHA to weed-out the
non-humans, but this has come under attacks. reference to recent news
items
http://www.garlic.com/~lynn/2008d.html#2 Spammer' bot cracks Microsoft's 
CAPTCHA


the ticket/cookie carries the clients public key (and whatever other
characteristics) ... which then can be used by the server(s) to
perform dynamic authentication (digital signing of some server
supplied, random data, countermeasure to replay attacks). this is in
lieu of server having to maintain the client account record ... ala a
RADIUS scenario where public key has been registered in lieu of a
password (some sort of online access to RADIUS account
records). various RADIUS public key in lieu of password postings:
http://www.garlic.com/~lynn/subpubkey.html#radius

the ticket/cookie scenario (with derived key encryption) is cross
between dynamic server-side account record data (say RADIUS
repository) and stale, static digital certificate scenario. as in the
transit gate operation, the ticket/cookie could also be retrieved,
decrypted, updated, re-encrypted, and returned as part of the
operation. initial server hand-shakes can include server sending some
random challenge data. The client returns the digital signature
and their previously obtained cookie. in the straight RADIUS public
key handshake scenario, just the digital signature and client
userid/account-number is returned since the rest of the cookie/ticket
equivalent info is online in the RADIUS account repository.

The straight RADIUS scenario would be to combine the server-side
random challenge data and combine it with the client registration
value (account number, userid) and whatever else the client-side
digital signing requires ... and return the userid/account-number
any other data and digital signature (i.e. server-side has to be
able to reconstruct what the client actually digitally signed
as part of verifying the digital signature). In the straight RADIUS
scenario, the public key (and any associated permissions, authorization,
etc) is obtained from the RADIUS repository. In cookie/ticket
scenario, it is obtained from the cookie/ticket appended to the
message.

The business process still has the initial registration phase
... where the original cookie is created (or in the RADIUS
scenario, where the userid definitiion is initially created) and the
public key is supplied (in lieu of a password).

This is also effectively the original certificateless pk-init scenario
for kerberos (aka public key in lieu of password)
http://www.garlic.com/~lynn/subpubkey.html#kerberos

The cookie scenario is standard client/server ... attempting
to eliminate the server having to retain the account
record on behalf of every client (as in either the RADIUS
and/or KERBEROS scenario). Encrypting of the cookie data
is standard ... although transit systems and financial transactions
have gone to derived key for the situation ... as countermeasure
to brute force attack on the infrastructure secret key.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-09 Thread Anne Lynn Wheeler

David Wagner wrote:

I'd be interested in hearing your take on why SSL client certs aren't
widely adopted.  It seems like they could potentially help with the
phishing problem (at least, the problem of theft of web authenticators
-- it obviously won't help with theft of SSNs).  If users don't know
the authentication secret, they can't reveal it.  The nice thing about
using client certs instead of passwords is that users don't know the
private key -- only the browser knows the secret key.

The standard concerns I've heard are: (a) SSL client supports aren't
supported very well by some browsers; (b) this doesn't handle the
mobility problem, where the user wants to log in from multiple different
browsers.  So you'd need a different mechanism for initially registering
the user's browser.

By the way, it seems like one thing that might help with client certs
is if they were treated a bit like cookies.  Today, a website can set
a cookie in your browser, and that cookie will be returned every time
you later visit that website.  This all happens automatically.  Imagine
if a website could instruct your browser to transparently generate a
public/private keypair for use with that website only and send the
public key to that website.  Then, any time that the user returns to
that website, the browser would automatically use that private key to
authenticate itself.  For instance, boa.com might instruct my browser
to create one private key for use with *.boa.com; later,
citibank.com could instruct my browser to create a private key for
use with *.citibank.com.  By associating the private key with a specific
DNS domain (just as cookies are), this means that the privacy
implications of client authentication would be comparable to the
privacy implications of cookies.  Also, in this scheme, there wouldn't
be any need to have your public key signed by a CA; the site only needs
to know your public key (e.g., your browser could send self-signed
certs), which eliminates the dependence upon the third-party CAs.
Any thoughts on this?
   


in AADS
http://www.garlic.com/~lynn/x959.html#aads
and certificateless public key
http://www.garlic.com/~lynn/subpubkey.html#certless

we referred to the scenario as person-centric ... as a contrast
to institutional-centric oriented implementations.

past posts in this thread:
http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch 
Transport Card Broken)
http://www.garlic.com/~lynn/aadsm28.htm#24 Fixing SSL (was Re: Dutch 
Transport Card Broken)
http://www.garlic.com/~lynn/aadsm28.htm#26 Fixing SSL (was Re: Dutch 
Transport Card Broken)


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-06 Thread Anne Lynn Wheeler

a recent reference

Research unmasks anonymity networks
http://www.techworld.com/security/news/index.cfm?newsID=11295
Research unmasks anonymity networks
http://www.networkworld.com/news/2008/020108-research-unmasks-anonymity.html
Research unmasks anonymity networks
http://www.arnnet.com.au/index.php/id;1270745171;fp;4194304;fpid;1
Paper Outlines Methods for Beating Anonymity Technology
http://www.darkreading.com/document.asp?doc_id=144606

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-03 Thread Anne Lynn Wheeler

StealthMonger wrote:


They can't be as anonymous as cash if the party being dealt with can
be identified.  And the party can be identified if the transaction is
online, real-time.  Even if other clues are erased, there's still
traffic analysis in this case.

What the offline paradigm has going for it is the possibility of true,
untraceable anonymity through the use of anonymizing remailers and
related technologies.

   


most people who heard the statement, understood that.

i think that possibly 2nd level detail was that they didn't want
PII easily associated by casual merchant. Initial response was to remove
name from payment cards  magstripes. This also precluded
merchants from requesting other forms of identification to
see if the names matched the name on the payment card.
The implication being that the payment infrastructure would
have to come up with other mechanisms to improve
the infrastructure integrity.

The offline payment paradigms ... while touting true
anonymity were actually primarily justified based on
other factors.

We had been asked to design and cost the dataprocessing
supporting US deployments of some of the offline products
(that were being used in Europe). Along the way, we did
some business process and revenue analysis and realized
that the primary motivation behind these system deployments
was the float.

About the same time that there was the EU about the
privacy of electronic retail payments ... there was also
a statement by the EU (and some of the country central
banks) that the offline products would be allowed to
keep the float for a short grace period  to help in
the funding of the infrastructure deployment ... but
after the grace period ... the operators would have to
start paying interest on the balance held in the offline
instruments (eliminating float from the equation).
After that, much of the interest in the offline
deployments drifted away.

In that time frame we had also done design, implementation
and deployment of a payment transaction infrastructure
supporting target marketing ... recent reference
http://www.garlic.com/~lynn/2008c.html#27 Diversity

support was for a small pilot of 60mil accounts and
1.5million transaction/day ... but capable of scaling
up to 20-30 times that amount. There was significant
attention paid to privacy issues and it was subject
to quarterly auditing by some dozen or so privacy
organizations. there had to be a large amount
of sensitive treatment of the information along
the lines of what HIPAA specifies for health information.

aka:

anonymized
 Previously identifiable data that have been deidentified and for
 which a code or other link no longer exists. An investigator would
 not be able to link anonymized information back to a specific
 individual. [HIPAA] (see also anonymous, coded, directly
 identifiable, indirectly identifiable)

as part of co-authoring x9.99 financial privacy standard, one
of the things we created was a privacy merged glossory and
taxonomy ... including GLBA, HIPAA, and EU-DPD references
some notes:
http://www.garlic.com/~lynn/index.html#glosnote

in our work on x9.59 financial transaction standard
http://www.garlic.com/~lynn/x959.html#x959

we made the statement that it was privacy agnostic ... since
the transactions were tied to accounts ... but then whether or
not the accounts were tied to individuals was outside the x9.59
standard
http://www.garlic.com/~lynn/subpubkey.html#x959

As a total aside ... as part of the Digicash liquidation,
we were brought in to evaluate the patent portfolio.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-01 Thread Anne Lynn Wheeler

Victor Duchovni wrote:


SMTP does not need TCP to provide reliability for the tail of the session,
the application-level . (end-of-data) and server 250 response complete
a transaction, everything after that is optional, so for example Postfix
will send (when PIPELINING).

DATACRLF354 Go ahead
Message-Content Lots of acks
.CRLFQUITCRLF   250 Ok

and will disconnect after reading the 250 response without waiting
for the 221 response. The TCP 3-way shutdown (FIN, FIN-ACK, ACK) happens
in the kernel in the background, the SMTP server and client are by that
point handling different connections. So the reliable shutdown latency
is of no consequence for application throughput.

A pipelined SMTP delivery can be completed over TCP in 5 RTTs not 7.

0. SYN  SYN-ACK
1. ACK  220
2. EHLO 250
3. MAIL RCPT DATA   250 250 354
4. MSG . QUIT   250 221
5. close socket

TCP is fine, latency is primarily the result of application protocol
details, not TCP overhead. The only TCP overhead above is 1 extra RTT
for the connection setup. Everything else is SMTP not TCP, and running
SMTP over UDP (with ideal conditions and no lost packets, ...) would
save just 1 RTT.

   

re:
http://www.garlic.com/~lynn/aadsm28.htm#21 Dutch Transport Card Broken

sorry, I didn't say that TCP required seven round-trips for reliable 
exchange;

the statement was that minimum TCP operation was seven packet
exchange (for reliable operation)  sort of 3.5 round-trips. That
VMTP (rfc 1045) reduced that to minimum of five packet exchange
(sort of 2.5 round-tips) ... and that XTP got it to a minimum of three
packet exchange (sort of 1.5 round-trips) for reliable operation.

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

rfc 1045 summary
http://www.garlic.com/~lynn/rfcidx3.htm#1045

1045 E
 VMTP: Versatile Message Transaction Protocol: Protocol specification,
 Cheriton D., 1988/02/01 (123pp) (.txt=264928) (Refs 955, 966, 969)
 (Ref'ed By 1050, 1072, 1105, 1106, 1190, 1263, 1323, 1453, 1458,
 1700, 2018, 2375, 2757) (VMTP)

as always, clicking on the .txt=nnn field (in rfc summary) retrieves 
the actual RFC.



If there is more than minimum amount of data ... TCP might involve more
than seven packet exchange ... but the minimum packet exchange is
seven packets (not round-trips).

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-01 Thread Anne Lynn Wheeler

Ian G wrote:
The PII equation is particularly daunting, echoing Lynn's early '90s 
experiences.  I am told (but haven't really verified) that the 
certificate serial number is PII and therefore falls under the full 
weight of privacy law  regs ... this may sound ludicrous, but privacy 
and security are different fields with different logics.  If that is 
true, the liability is far too high for something that should be 
private, but is already public by dint of its exposure in 
certificates.  Privacy liabilities are sky-high in some places, and 
not only that, they are incalculable, unknowable, and vary with the 
person you are talking to.


So a superficial conclusion would be don't use client certificates 
because of the privacy issues although the issues are somewhat more 
complex than PII revealed in SSL key exchange.


As I say, they'll plug on, as they need to prove that the cert is 
worth issuing.  It's a data point, no more, and it doesn't exactly 
answer your spec above.  But I'm having fun observing them trying to 
prove that client certs are worth any amount of effort.
the problem that digital certificates were suppose to address was first 
time communication
between strangers ... the electronic analogy of the letters of 
credit/introduction from
sailing ship days. this harks back to the offline email days of the 
early 80s ... dial-up
electronic post-office, exchange email, hangup, and now authenticate 
first-time email

from total stranger.

the design point assumptions are invalidated if the relying party has 
their own
repository of information about the party being dealt with (and therefor 
can
included that party's public key) and/or has online, timely electronic 
access to

such information.

one of my favorite exchanges from the mid-90s was somebody claiming that
adding digital certificates to the electronic payment transaction 
infrastructure

would bring it into the modern age. my response was that it actually would
regress the infrastructure at least a couple decades to the time when
online, real-time transactions weren't being done. The online, real-time
transaction provides much higher quality and useful information than
a stale, static digital certificate (with an offline paradigm from before
modern communication). Having an available repository about the party
being dealt with ... including things like timely, aggregated information
(recent transactions) is significantly mover valuable than the stale,
static digital certificate environment (the only thing that it has going
for it, is it is better than nothing in the oldtime offline environment).

misc. past posts referencing certificate-less public key operation
http://www.garlic.com/~lynn/subpubkey.html#certless

for some real topic drift ... i've mentioned x9.59 financial
standard protocol that can use digital signatures for
authentication w/o requiring digital certificates
http://www.garlic.com/~lynn/x959.html#x959

part of the issue included that digital certificates
(even relying party only digital certificates) can
add a factor of one hundred times payload bloat
to a typical payment transaction
http://www.garlic.com/~lynn/subpubkey.html#bloat

however, we were also got involved in co-authoring
the x9.99 privacy standard ... as part of that we had
to look at a number of things, HIPAA, GLBA ... as
well as EU-DPD. as part of that we had also done
a privacy merged taxonomy and glossary ... some
notes
http://www.garlic.com/~lynn/index.html#glosnote

EU had also made a statement in the mid-90s that
electronic retail payments should be as anonymous
as cash. The dominant use of SSL in the world
today is electronic commerce between a consumer
and a merchant. Passing a client certificate (with
PII information) within an encrypted SSL channel
to a merchant ... still exposes the information to
the merchant ... also violating making purchases
as anonymous as cash.








-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-02-01 Thread Anne Lynn Wheeler

Nicolas Williams wrote:

I don't have one that exists today and is practical.  But we can
certainly imagine possible ways to improve this situation: move parts of
TLS into TCP and/or IPsec.  There are proposals that come close enough
to this (see the last IETF SAAG meeting's proceedings, see the IETF BTNS
WG) that it's not too farfetched, but for web stuff I just don't think
they're remotely likely.

   


my view of ipsec was that it faced a significant barrier to entry since
it required upgrading lots of installed kernels all over the infrastructure
(aka tcp/ip protocol stack have been integrated kernel implementations)

both SSL and VPN offered implementations that require having to
upgrade existing deployed kernels (something that has gotten
somewhat easier in the last decade plus).

about the same time as SSL, a friend that we had worked on  off with
over a couple decades introduced what was to become called VPN
in gateway committee at fall '94 IETF meeting in san jose.

my view was this resulted in some amount of consternation
with the ipsec forces as well as some of the router vendors.
the ipsec forces were somewhat mollified by being able
to refer to vpn as lightweight ipsec (while others then
would refer to ipsec as heavyweight ipsec).

the initial proposal involved border routers providing
authentication and (encryption) tunneling through the
internet. some of the router vendors had processors
that could handle the encryption load. however, there
was opposition from the router vendors that didn't
have products with processors that could handle
the encryption load (or at least stalling until they
had such a product).

in any case, uptake of both SSL and VPN ... was
the significantly easier and less complex deployment
... vis-a-vis ipsec.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-31 Thread Anne Lynn Wheeler

Victor Du

Jumping in late, but the idea that *TCP* (and not TLS protocol design)
adds round-trips to SSL warrants some evidence (it is very temping to
express this skepticism more bluntly).

With unextended SMTP for example, the minimum RTT count is:

0. SYN  SYN-ACK
1. ACK  220
2. HELO 250
3. MAIL 250
4. RCPT 250
... n recipients
   RCPT 250
4+n DATA 354
5+n ... stream of message content segmentsCRLF.CRLF
250

so it takes at least 6 RTTs to perform a delivery (of a short
single-recipient message), but only 1 of the 6 RTTs is TCP
overhead. This is improved with PIPELINING:

0. SYN  SYN-ACK
1. ACK  220
2. EHLO 250 ... PIPELINING ...
3. MAIL RCPT(n times) DATA  250 250 (n times) 354
4. ... stream of message content segmentsCRLF.CRLF
250
   

re:
http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch 
Transport Card Broken)


TCP requires minimum of seven message exchange for reliable transport
 VMTP (rfc 1045) got that down to minimum of five messages, and XTP 
then

got it down to three messages minimum for reliable transport (disclaimer
we were on the XTP technical advisory board).

i've frequently pontificated that with reliable registration of public keys
in the dns system and then piggy-backing any registered public key in
standard DNS response  then it would be possible to encode the
randomly generated secret key (with that public key) and the encrypted
message in the XTP packet for minimum 3 packet exchange.
http://www.garlic.com/~lynn/subtopic.html#subpubkey.html#catch22

http already went thru its period of problems of implicit assumptions
with tcp. tcp sessions were assumed to be long lived and session shutdown
was assumed to be relatively infrequently. non-session activity like http
was always assumed to use udp for efficiency. the http ignored all of
that and used tcp for non-session activity. as a result, webserver systems
went thru a period where the processors was spending 95+ percent of
processor in the session shutdown processing. systems then were retrofited
with new kind of tcp session shutdown implementation to handle the
misuse by http.

the original ssl deployment was to 1) encrypt data in transit and
2) authenticate the server. the implicit assumption was that the
user understood the binding between the business and the url.
the browser then provided the second part, verifying the binding
between the url and the server contacted (was the server that
the user thot they were talking to, the server they were actually
talking to).

The dependency for valid ssl operation was violated almost
immediately when merchants found that ssl overhead reduced thru
thruput by 5-10 times. the regression was instead of initial contact
of the webserver (presumably url supplied by user) being ssl,
ssl was moved to checkout/pay phase where the user clicked
on a button (and url) provided by the webserver (not a url
provided by the user). It was no longer possible to provide
any assurances as to the authentity of the webserver contacted
(ssl purely being reduced to encrypting data in transmission).

we had been called in to consult with the small client/server
company on using this technology (they created) called SSL
for payment transactions
http://www.garlic.com/~lynn/subnetwork.html#gateway

and had to go thru detailed walk thrus of the technology as
it applied to actual business processes (and the associated
implicit dependencies) ... as well as detailed walk thrus of the
new business operations that were calling themselves
certification authorities.

the other issue that we came up in applying this SSL technology
was communication between webservers and something called
the payment gateway. for  this communication we mandated mutual
authentication ... this was before mutual authentication had
been implemented in SSL. It turns out that by the time
we had it all implemented and deployed ... it also became
very apparent that the things called digital certificates
were redundant and superfluous.

the basic design point for digital certificates is first time
communication between total strangers. the payment gateway
business processes required that all the merchants had
to be pre-registered with the payment gateway and the payment
gateway pre-registered with all the merchants  violating the
basic justification for having digital certificates.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-01-30 Thread Anne Lynn Wheeler

Philipp Gühring wrote:

Yes, sending client certificates in plaintext while claiming that SSL/TLS is
secure doesn´t work in a world of phishing and identity theft anymore.

We have the paradox situation that I have to tell people that they should use
HTTPS with server-certificates and username+password inside the HTTPS
session, because that´s more secure than client certificates ...

Does anyone have an idea how we can fix this flaw within SSL/TLS within a
reasonable timeframe, so that it can be implemented and shipped by the
vendors in this century?

(I don´t think that starting from scratch and replacing SSL makes much sense,
since it´s just one huge flaw ...)

   

re:
http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken

aka ... that was part of the relying-party-only certificates from the 
mid-90s;

http://www.garlic.com/~lynn/subpubkey.html#rpo

i.e. the x.509 identity digital certificates from the early 90s, were 
becoming

more and more overloaded with personal information ... and by the
mid-90s, lots of institutions were starting to realize all that personal
information represented significant privacy and liability issues ... and
the RPO digital certificates were born.

However, it was trivial to demonstrate that (for all those business 
processes)

that the digital certificates were redundant and superfluous (however, there
was some amount of industry brain washing that digital certificates were
mandatory ... especially if digital signatures was used ... even if they
served no useful purpose).

this also showed up in work on pk-init for kerberos supporting digital
signature authentication ... and got into the confused mess with redundant
and superfluous digital certificates
http://www.garlic.com/~lynn/subpubkey.html#kerberos

and similarly digital signatures for radius
http://www.garlic.com/~lynn/subpubkey.html#radius

(between kerberos and radius, they represent possibly the majority
of authentication in the world today)

part of the confusion regarding the necessity for digital certificates
could be seen in the X9F financial standards work ... the appending
of even a relying-party-only digital certificate (lacking any personal
information) could represent a factor of 100 times payload bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat

for a nominal electronic payment transactions (and also 100 times
processing bloat). as a result, there was some standardization
effort looking at compressed (relying party only) digital certificates
(even tho they were serving no useful purpose), attempting to
get the payload bloat down to possibly only 5-10 times (instead
of 100 times). I took the opportunity to demonstrate that it
would be logically possible to compress such digital certificates
to zero bytes ... totally eliminating the payload bloat. then rather
than advocating the elimination of totally useless, redundant
and superfluous digital certificates
http://www.garlic.com/~lynn/subpubkey.html#certless

there could be an infrastructure that mandated zero-byte
digital certificates appended to every transaction.





-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Lack of fraud reporting paths considered harmful.

2008-01-27 Thread Anne Lynn Wheeler

Perry E. Metzger wrote:

This evening, a friend of mine who shall remain nameless who works for
a large company that regularly processes customer credit card payments
informed me of an interesting fact.

His firm routinely discovers attempted credit card fraud. However,
since there is no way for them to report attempted fraud to the credit
card network (the protocol literally does not allow for it), all they
can do is refuse the transaction -- they literally have no mechanism
to let the issuing bank know that the card number was likely stolen.

This seems profoundly bad. I hope that someone on the list has the
right contacts to get the right people to do something about this.

   


some chance they are doing this to save money on transactions that aren't
likely to be approved ... i.e. rather than be charged for a transaction that
they send thru to the issuer that they are sure to be rejected ... they
reject it upfront.

now the associations have standard procedure to perform stand-in when
the network accepts a transaction from an acquirer but isn't able to forward
it to the issuer. stand-in allows the network to decide whether to approve
or reject the transaction using simplified rules. later, when contact is
re-established with the issuer ... the issuer has to be informed of all
the stand-in activity.

a possible simplified mechanism is to be able to generate a simulated 
stand-in

report of rejected transactions. the issue then in such a simulated stand-in
role ... for all the reasons that they chose to reject a transaction ... 
do they map

into the standard iso 8583 codes for reasons that the issuer would reject
the transaction.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-25 Thread Anne Lynn Wheeler

Aram Perez wrote:
Not to defend the designers in any way or fashion, but I'd like to 
ask, How much security can you put into a plastic card, the size of a 
credit card, that has to perform its function in a secure manner, all 
in under 2 seconds (in under 1 second in parts of Asia)? And it has to 
do this while receiving its power via the electromagnetic field being 
generated by the reader.
we sort of saw that in the mid-90s when we were doing the x9.59 
financial standard

http://www.garlic.com/~lynn/x959.html#x959

and getting comments that it wasn't possible to have both low cost and 
high security at
the same time. we looked at it and made the semi-facetious statements 
that we
would take a $500 milspec part and aggresively cost reduce it by 2-3 
orders of magnitude

will improving the security. along the way we got tapped by some in the
transit industry to also be able to meet the (then) transit gate 
requirements

(well under 1 second and do it within iso 14443 power profile).

part of it was having to walk the whole end-to-end process ... all the 
way back

to chip design and fab manufacturing process ... little drift about walking
fab in a bunny suit
http://www.garlic.com/~lynn/2008b.html#13

we effectively did get it on close to the RFID chip (i.e. the one that they
are targeting for UPC) technology curve ... i.e. chip fabrication cost 
is roughly
constant per wafer ... wafer size and circuit size have been leading to 
higher
number of chips per wafer (significantly reducing cost/chip). As circuit 
size

shrank with a corresponding shrinkage in the size of chips (that didn't have
corresponding increase in number of circuits) there was a blip on the
cost/chip curve as the area of the cuts (to separate chips in the wafer)
exceeded the (decreasing) chip size.  Earlier this decade there was
a new cutting process that significantly reduced the cut area ... allowing
yield of (small) chips per wafer to continue to significantly increase
(allowing pushing close to four orders of magnitude reduction ... rather
than 3-4 orders of magnitude reduction).

aads chip strawman references
http://www.garlic.com/~lynn/x959.html#x959




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Dutch Transport Card Broken

2008-01-25 Thread Anne Lynn Wheeler

my impression has been that with lack of takeup of various kinds of security
solutions that were extensively marketed in the 90s ... that the current
situation has many of those same organizations heavily involved in behind
the scenes lobbying

saw some of that nearly a decade ago when we were brought in to
help wordsmith the cal. state electronic signature legislation which
led to also be brought in on federal electronic signature legislation
... some past posts
http://www.garlic.com/~lynn/subpubkey.html#signature

some other references ...

Hackers break into transport smart card
http://www.dutchnews.nl/news/archives/2008/01/german_hackers_break_transport.php
Transport smart card hacked again (update)
http://www.dutchnews.nl/news/archives/2008/01/transport_smart_card_hacked_ag.php

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Death of antivirus software imminent

2008-01-03 Thread Anne Lynn Wheeler

Leichter, Jerry wrote:

Virtualization has become the magic pixie dust of the decade.

When IBM originally developed VMM technology, security was not a primary
goal.  People expected the OS to provide security, and at the time it
was believed that OS's would be able to solve the security problems.
  

re:
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software 
iminent
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software 
iminent
http://www.garlic.com/~lynn/aadsm28.htm#8 Death of antivirus software 
iminent


the other claim was that it was assumed that basic systems were built to 
be secure,
so it would have been quite foreign idea it would be necessary to build 
a secure

specific system.

besides the referenced fairly wide use of gov and commercial 
institutions requiring
high integrity systems ... the early virtual machine systems (cp67 and 
vm370)

were also used by commercial time-sharing service bureaus. most of these
created cms padded cell modifications, a lot of it was to prevent 
users from

damaging themselves (as opposed to the underlying security that prevented
uses from damaging the system and/or each other).

at least some of these services provided online, concurrent services to
(competitive) wall street firms ... who would be using the online services
for highly sensitive financial activities (as example of integrity 
requirements).


a little related x-over from posting in this thread
http://www.garlic.com/~lynn/2008.html#14 hacked TOPS-10 monitors

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Death of antivirus software imminent

2008-01-02 Thread Anne Lynn Wheeler

Bill Frantz wrote:
 My favorite virtual machine use is for the virus to install itself
 as a virtual machine, and run the OS in the virtual machine.  This
 technique should be really good for hiding from virus scanners.

re:
http://www.garlic.com/~lynn/aadsm28.htm#2 Death of antivirus software 
imminent
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software 
imminent


i commented on that in reference posts mentioning that there have been
uses of virtual machines to study virus/trojans ... but that
some of the new generation virus/trojans are now looking to see if they
are running in virtual machine (studied?).

some of the current trade-off is whether that virtual machine technology
can be used to partition off basically insecure operations (which are widely
recognized as being easy to compromise) and then completely discard
the environment and rebuild from scratch after every session (sort of
the automated equivalent of having to manually wipe an infected machine
and re-install from scratch).

the counter argument is that crooks can possibly also use similar
technology to hide ... once they have infected the machine. the current
issue is that a lot of the antivirus/scanning techniques are becoming 
obsolete

w/o the attackers even leveraging virtual machine technology.

The attackers can leverage the technology in an otherwise poorly
defended machine. Some years ago there was a product claiming
that it could operate even at a public access machine because
of their completeness of their antivirus countermeasures ... even
on an infected machine. I raised the issue that it would be trivial
to defeat all such countermeasures using virtual machine technology.
Somewhat of a skirmish resulted since they had never considered
(or heard of) virtual machine technology ... for all i know there
is still ongoing head-in-the-sand situation.

for little topic drift ... this blog entry:
https://financialcryptography.com/mt/archives/000991.html

and
http://www.garlic.com/~lynn/aadsm28.htm#3
http://www.garlic.com/~lynn/aadsm28.htm#5

there is some assertion that the crooks overwhelming the
defenders countermeasures because they are operating
significantly faster and more efficiently.

however, another interpretation is that the defenders
have chosen extremely poor position to defend ... and are
therefor at enormous disadvantage. it may be necessary
to change the paradigm (and/or find the high ground)
in order to successfully defend.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Death of antivirus software imminent

2007-12-30 Thread Anne Lynn Wheeler

re:
Storm, Nugache lead dangerous new botnet barrage
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1286808,00.html

from above:

The creators of these Trojans and bots not only have very strong 
software development and testing skills, but also clearly know how 
security vendors operate and how to outmaneuver defenses such as 
antivirus software, IDS and firewalls, experts say. They know that they 
simply need to alter their code and the messages carrying it in small 
ways in order to evade signature-based defenses. Dittrich and other 
researchers say that when they analyze the code these malware authors 
are putting out, what emerges is a picture of a group of skilled, 
professional software developers learning from their mistakes, improving 
their code on a weekly basis and making a lot of money in the process.


... snip ...

... and somewhat related

Virtualization still hot, death of antivirus software imminent, VC says
http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html

from above:

Another trend Maeder predicts for 2008 is, at long last, the death of 
antivirus software and other security products that allow employees to 
install and download any programs they'd like onto their PCs, and then 
attempt to weed out the malicious code. Instead, products that protect 
endpoints by only allowing IT-approved code to be installed will become 
the norm.


... snip ...

and post about dealing with compromised machines
http://www.garlic.com/~lynn/2007u.html#771 folklore indeed

mentioning sophistication in other ways:

Botnet-controlled Trojan robbing online bank customers
http://www.networkworld.com/news/2007/121307-zbot-trojan-robbing-banks.htm

from above:

If the attacker succeeds in getting the Trojan malware onto the victim's
computer, he can piggyback on a session of online banking without even
having to use the victim's name and password. The infected computer
communicates back to the Trojan's command-and-controller exactly which
bank the victim has an account with. It then automatically feeds code
that tells the Trojan how to mimic actual online transactions with a
particular bank to do wire transfers or bill payments

... snip ...

there have been some number of online banking countermeasures for
specific kinds of system compromises  like keyloggers ... but they
apparently didn't bother to get promises from the crooks to only limit
the kinds of attacks to those exploits.

some related comments on such compromised machines
http://www.garlic.com/~lynn/aadsm27.htm#66 2007: year in review
http://www.garlic.com/~lynn/aadsm28.htm#0 2007: year in review

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: 2008: The year of hack the vote?

2007-12-29 Thread Anne Lynn Wheeler

Jack Lloyd wrote:
 The only reason this 'must' be true is because an anonymous and secure
 payment system is a terror which thankfully our federal governments
 and central banks protect us from. While Amazon and others obviously
 like being able to build customer profiles of everyone, I don't doubt
 that they would be perfectly willing to accept an anonymous payment as
 long as the money is good (and, of course, that the transaction costs
 are no more than a credit card and/or the order flow is sufficient
 that it is worth building support for it).

in the mid-90s, the x9a10 financial standard working group had
been given the requirement to preserve the integrity of the
financial infrastructure for all retail payments ... which resulted
in the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959

in the same timeframe, the EU (in conjunction with eu-dpd)
made statements that electronic payments at point-of-sale
should be as anonymous as cash.

this was interpreted as meaning that names should be
removed from payment cards (plastic and magstripe).
the contention was that (because of poor authentication)
retail outlets could cross-check names on the cards against
some other form of ID. the implication that removing
names might help promote other integrity measures.

in the x9.59 standard, we claimed that the improved
integrity allowed meeting the EU-DPD objectives.
We also claimed that x9.59 was privacy agnostic
i.e. it allowed for privacy. The ALL requirement
given to the x9a10 financial standard working
group met internet, face-to-face, point-of-sale,
electronic commerce. It also met debit, credit,
ACH, as well as stored-value cards ... aka the
same X9.59 was applicable to *ALL*. In the debit/credit
scenario some countries have know your customer
mandates associating account numbers with individuals
... which we claimed was outside the x9.59 standard.
Supposedly with appropriate regulated access to
information, govs can obtain information associating
account activity with individuals.

However, the very same x9.59 standard also works
with stored-value/gift cards ... which doesn't have
similar know your customer mandates.
http://www.garlic.com/~lynn/subpubkey.html#privacy

And in fact, most stored-value/gift cards share a lot
of the same exact processing with the debit/credit
processing ... the addition of x9.59 could provide for
the exactly same level of integrity thruout debit,
credit, and stored-value/gift processing.

for other drift, in the mid-90s ... there were some
of the other payment efforts specifically for the
internet which had so much payload and processing bloat
that it made it impractical past the toy demo stage
http://www.garlic.com/~lynn/subpubkey.html#bloat

related recent post on infrastructure provisioning and bloat of
toy demos:
http://www.garlic.com/~lynn/2007v.html#64 folklore indeed

about the same time, there were completely different
chip card oriented efforts for point-of-sale. one of the
scenarios of some of the chipcard pilot projects in
the late 90s and early part of this century was that
they managed to increase the vulnerabilities
(magstripe vis-a-vis chipcards)
http://www.garlic.com/~lynn/subintegrity.html#yescard

the common excuse from the period, was that chips
cost so much that it wasn't possible to afford integrity
that actually improved over magstripe. The other
possible observation was that some of the chipcard
efforts were so chip myopic ... that they couldn't
realize that they were actually making it worse
for the overall infrastructure.

A big issue for merchants isn't anonymous payments
... it is cost of doing business. This has been in
the news quite a bit recently in the form of
interchange fees ... recent posts
http://www.garlic.com/~lynn/2007v.html#62 folklore indeed

the other area is in the liability related to breaches
(and/or the costs of countermeasures to breaches).

i've mentioned before that we had been called in
to consult with small client/server startup that wanted
to do payments on their server. They had this technology
they called SSL and it is frequently now referred to
as electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

and then we got dragged into involved with the x9a10
financial standard. as part of attempting to meet the
requirement to preserve the integrity of the financial
infrastructure for all retail payments ... we did some detailed
threat and vulnerability analysis. A big item that came out
were infrastructure vulnerabilities ... breaches, skimming,
harvesting, evesdropping, ... a whole slew of things.

we identified that much of the vulnerability could be
attributed to the account number and transaction
information has diametrically opposing requirements
... 1) it has to be readily available for large number of
different business processes and 2) since the crooks
can use the same information for various kinds of
essentially replay attacks ... the information has to
be kept confidential and never 

Re: Fingerprint Firefox Plugin?

2007-10-24 Thread Anne Lynn Wheeler

zooko wrote:
Suppose you did have a convenient way to display the SSL certificate for 
every site whenever you loaded a page from the site. You probably 
wouldn't want to memorize all the certificates for the secure sites that 
you care about, so you might instead write some notes on a piece of 
paper next to your computer, for example writing down an SSL certificate 
and then next to it writing bank, and then writing down another one 
and then next to it writing mail, and so on.


Then, whenever you load a page, you would look at the SSL certificate 
that is linked to that page and glance at your notepad to see which 
description it maps to. If you are looking at a random web site that 
you've never seen before, and the certificate doesn't appear on your 
notes, then no big deal. If you are looking at a page that appears to 
belong to your bank, and the certificate that came with that page 
doesn't appear on your notes, then this is a big red flag! Likewise, if 
you are looking at a page that appears to belong to your bank, and the 
certificate appears on your notes, but the note next to it doesn't say 
bank, then this is a red flag, too! For example, it might be the 
certificate of your mail service, which appears on your paper along with 
the note mail. Or it might just be a certificate that appears on your 
paper along with the note joke site from Harry.


Note that a system which classified certificates into trusted or 
untrusted categories might give you the green flag even when a 
certificate that you trust to serve up good jokes is serving up 
something that appears to be your bank account.


So, the thing about writing down certificates and mapping them to short 
hand-written notes is what the Pet Name Toolbar automates for you:


https://addons.mozilla.org/en-US/firefox/addon/957



the design point for certificates was first time communication between total
strangers (aka the letters of credit/introduction from sailing ship days).

certificates have also somewhat tried moving into no-value market segment for 
relying
parties that had no (and/or couldn't cost justify) mechanism for recording 
information
about other parties they were dealing with. 

by comparison pgp had assumed some mechanism for relying parties being able to 
record information about the parties that they had dealings with. huge number of

infrastructures have had well entrenched infrastructures for recording 
information
about parties that they dealt with ... it just has been that the authentication
related information (for these infrastructures) have tended to be shared 
secrets.
many of these infrastructures could have been upgraded from shared secrets
to public key ... w/o having any impact on the business and/or trust models
... and furthermore by the very nature of the existing infrastructures,
the paradigm behind digital certificates wasn't applicable (i.e. digital
certificates being totally redundant and superfluous).

recent thread/posting about it being much more natural for simple upgrade 
of kerberos infrastructure from shared secrets to public key ... w/o the

exorbitant additional overhead and processing introduced by digital
certificates. 
http://www.garlic.com/~lynn/2007q.html#2 Windows Live vs Kerberos

http://www.garlic.com/~lynn/2007q.html#5 Windows Live vs Kerberos

when we were called in to consult with this small client/server startup
that wanted to do payment transactions on their server ... since then
somewhat has come to be called electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

one of the technologies they had invented was SSL ... and we had
to do some work on applying SSL to real business processes and also
do some end-to-end audits of the whole series of operations ... including
these things that we calling themselves certification authorities

one of the things that undermined original assumptions applying
SSL to business processes was the whole click paradigm ... discussed
in more detail in this recent post
http://www.garlic.com/~lynn/2007q.html#30 


and the assumptions about SSL as countermeasure and the related
threat models.

another aspect of SSL, certification authorities, digital certificates
was the whole issue behind what is met by certification process ... and
what certifications were represented by digital certificates. 


during the initial decade or so of electronic commerce something over
70 percent of the transactions were done by less than 100 websites
(activity is highly skewed) These websites were both well known and 
also carried a lot of repeat business ... invalidating one of the 
original/primary justifications  for having digital certificates. 
so a very few websites did majority of transactions and didn't 
need certification. by comparison, the vast majority of websites

were only doing a very, very few electronic transactions
(especially those involving large percentage of first interaction
between complete strangers) ... and couldn't cost justify 

Re: a fraud is a sale, Re: The bank fraud blame game

2007-07-09 Thread Anne Lynn Wheeler

re:
http://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank 
fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank 
fraud blame game

recent item with the other side of the issue (as opposed to being able
to profit when merchants have fraud)

Data Security Advanced by New Aleratec Multi-purpose DVD/CD Shredder 
http://www.emedialive.com/Articles/ReadArticle.aspx?ArticleID=12940


from above:

Identity Theft and Fraud cost business $600 billion a year, according to the
Association of Certified Fraud Examiners. 

.. snip ... 


post from earlier this spring about series of articles essentially appearing
simultaneously:
http://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a 
high priority for 2007

ID fraud down, except credit cards
http://www.pcadvisor.co.uk/news/index.cfm?newsid=8280
Survey: ID fraud in U.S. falls by $6.4B
http://www.computerworld.com/action/article.do?command=viewArticleBasicarticleId=9010082aintsrc=hm_list
Survey Indicates ID Theft May Be Diminishing
http://yro.slashdot.org/yro/07/02/01/2127224.shtml
Study: ID fraud in decline
http://www.securityfocus.com/brief/423
US ID theft losses decline
http://www.astalavista.com/?section=newscmd=detailsnewsid=3376
US ID theft losses decline
http://www.theregister.com/2007/02/05/us_id_fraud_survey/

and

ID Theft Is Exploding In The U.S.
ttp://www.informationweek.com/news/showArticle.jhtml?articleID=197800774
ID fraud soaring across the pond
http://www.silicon.com/financialservices/0,3800010322,39166236,00.htm

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The bank fraud blame game

2007-07-05 Thread Anne Lynn Wheeler

R. Hirschfeld wrote:

- differential pricing: electronic purse payments are potentially
  cheaper to process than those of debit cards because they are
  offline, but consumers find it more convenient to keep money in
  their bank account than on a smart card and will likely continue to
  do so as long as it costs no more.  (This may become less of an
  issue if/when all vending machines and parking meters are on the
  internet anyway.)


re:
http://www.garlic.com/~lynn/aadsm27.htm#41 The bank fraud blame game

in the mid-90s a number of US financial institutions looked at the economics
of the EU chipcard electronic purses (modulo the float issue ... which could
be made to work) the issue was that the (much more) expensive chips were
being used to offset the significantly higher PTT costs (and/or just plain
PTT availability) in Europe.

The US could deploy a magstripe authentication card for stored-value ... that
did online transactions using much of the existing online point-of-sale
infrastructure ... for significantly lower overall infrastructure costs
than the EU chip-based offline stored value. The magstripe card basically
became a something you have authentication mechanism. The primary trade-off
issue was that the US telecom pricing was so much lower than in Europe
(and lots of 80s  90s design in europe was being driven by the extremely
high PTT costs and/or, in some cases, lack of PTT availability).

Note, however, the internet along with various telcom and technology changes 
around the world have contributed to significantly changing the online/offline 
economic trade-off considerations.


Independent of the online/offline economic issues ... there are some fraud
and security issues that could drive towards using chips for a more secure
something you have authentication device.

however, there is some lingering effects from the older high PTT costs
related to chip-based architectures ... and whether there are any residual
design features related to (originally) supporting offline operation.

Part of this could be seen in the yes card exploits ... where, transaction
business rules were left in the chip implementation (as oppsed to the chip
being purely an authentication mechanism) ... contributing to the enormous 
vulnerability increase

http://www.garlic.com/~lynn/subintegrity.html#yescard

For the float issue with regard to this class of US gift/stored-value cards 
... they are sold as merchant cards ... i.e. the kind of gift  stored-value cards

you see used by coffee shops, video rental, grocery stores, large department
stores, etc. Possibly, in part, because they are merchant cards ... as
opposed to bank cards ... the associated accounts and balances are
pretty far removed from any jurisdiction that might impose payment of
interest. 


misc. past posts about how the large difference in telecom costs drove different
solutions
http://www.garlic.com/~lynn/aepay11.htm#28 Solving the problem of micropayments
http://www.garlic.com/~lynn/aepay11.htm#70 Confusing Authentication and 
Identiification? (addenda)
http://www.garlic.com/~lynn/aadsm16.htm#12 Difference between TCPA-Hardware and 
a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm18.htm#39 Financial identity is *dangerous*? 
(was re: Fake companies, real money)
http://www.garlic.com/~lynn/aadsm21.htm#12 Payment Tokens
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital 
cash
http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security 
requested
http://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security 
requested
http://www.garlic.com/~lynn/2002d.html#41 Why?
http://www.garlic.com/~lynn/2002e.html#22 Opinion  on smartcard security 
requested
http://www.garlic.com/~lynn/2003h.html#54 Smartcards and devices
http://www.garlic.com/~lynn/2004j.html#39 Methods of payment
http://www.garlic.com/~lynn/2004j.html#43 Methods of payment
http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The bank fraud blame game

2007-07-05 Thread Anne Lynn Wheeler

R. Hirschfeld wrote:

During the course of the CAFE project some commercial electronic purse
systems emerged, notably Proton (from Banksys in Belgium, replicated
in other counties under other names) and Mondex.  These were in many
ways less sophisticated than CAFE's system (which was multi-issuer,
multi-currency, privacy-respecting, etc.) but had serious commercial
backing.  For the most part these seem to have stagnated or died.  I
suspect that getting them to catch on would require drastic measures
such as:


we had gotten tasked to do a design and costing of mondex implementation
in the states (all the transaction processing dataprocessing, sizing
capacity and resources, etc) ... and looking at pricing various kinds
of mondex related transactions (super brick from mondex international
and how it flowed thru the rest of the infrastructure).

the conclusion we came up with was that nearly all the financial
justification for mondex was in the float. later there were scenarios
where mondex international was encouraging deployment in various
countries by offering to split the float with the chartered
mondex national body (and then it seemed like float offerings were
starting to peculate down to financial institutions lower in
the mondex hierarchy)

then along came an EU statement that mondex (and similar implementations)
would only be given a grace period with regard to retaining the float
(as a mechanism to underwrite start-up costs) ... but after a period
of 2-3 yrs, they were then going to be required to start paying interest on
balances carried in the cards. after that, much of the interest(?) seemed
to evaporate.

separately there were some issues with the chip technology being
used in the mondex cards.

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

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The bank fraud blame game

2007-07-03 Thread Anne Lynn Wheeler

Adam Shostack wrote:

It may be, indeed.  You're going (as Lynn pointed out in another post)
to be fighting an uphill battle against the last attempts.  I don't
think smartcards (per se) are the answer.  What you really need is
something like a palm pilot, with screen and input and a reasonably
trustworthy OS, along with (as you say) the appropriate UI investment.


given the recognition of the serial port issues from the earlier, dial-in
online banking ... providing a strong motivation to transfer responsibility
for all such problems to ISPs (under the guise of moving to the internet)
http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game

that even the transfer of a little bit of institutional knowledge would
have enabled the avoidance of later smartcard reader deployment disasters
http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game

However, following some of the early yes card deployments
http://www.garlic.com/~lynn/subintegrity.html#yescard

it appeared to be more of a case where smartcard organizations were
very narrowly focused on purely smartcard issues and ignoring 
everything else.


that aspect was highlighted in an early presentation about circumstances
surrounding the yes card ... and there was a somewhat
uncontrolled comment from somebody in the audience do you mean to say 
that they managed to spend a  billion dollars to prove that chips are 
less secure than magstripes.


misc. old posts/threads mentioning the pc/sc serial port issue  smartcard
reader deployment disasters
http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed 
Flowers
http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
http://www.garlic.com/~lynn/2002m.html#37 Convenient and secure eCommerce using 
POWF
http://www.garlic.com/~lynn/2002m.html#39 Convenient and secure eCommerce using 
POWF

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: a fraud is a sale, Re: The bank fraud blame game

2007-07-03 Thread Anne Lynn Wheeler

Ed Gerck wrote:

Yes. Today, under current practice, there's actually a strong
incentive to keep existing fraud levels than to try to scrub
it out -- fraud has become a sale:


thread from earlier this year ... when over a period of a month or
so there were several releases that essentially had fraud declining
by 10-15 percent simultaneously with fraud increasing by 200-300 percent.
http://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a 
high priority for 2007
http://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a 
high priority for 2007
http://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a 
high priority for 2007
http://www.garlic.com/~lynn/2007e.html#61 Securing financial transactions a 
high priority for 2007
http://www.garlic.com/~lynn/2007e.html#62 Securing financial transactions a 
high priority for 2007
http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, 
dies
http://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007i.html#19 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007m.html#65 nouns and adjectives

this followed an article pointing out that EU financial institutions
had something less than 10percent of their bottom line coming from
payment transaction operation ... while it was closer to 40percent
for US financial institutions.
http://www.garlic.com/~lynn/2007k.html#12 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#13 IBM Unionization
http://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based

and articles about interchange fee represents the single large expense for some 
retail
merchants
http://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment 
systems
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX 
Laptop
http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high 
priority for 2007
http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a 
high priority for 2007
http://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007i.html#72 Free Checking

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The bank fraud blame game

2007-07-02 Thread Anne Lynn Wheeler

Adam Shostack wrote:

I'd suggest starting from the deployment, training, and help desk
costs.  The technology is free, getting users to use it is not.  I
helped several banks look at this stuff in the late 90s, when cost of
a smartcard reader was order ~25, and deployment costs were estimated
at $100, and help desk at $50/user/year.


re:
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game

there was a detailed analysis of the 99/00 smartcard deployments ... looking 
at the most common causes for problems. this was overlapped with opinion
claimed to be widely held among consumer financial institutions, that it had 
been proven that smartcards were not practical in the consumer market segment.


for something of a lark, at the annual smartcard conference, i went around to
most of the booths asking people at the booth if they were 1) aware 
that the financial industry considered smartcard not practical in the

consumer market segment and 2) what was the cause of the majority of the
problems.

some of the major deployments selected to be pc/sc compliant ... which at the
time only supported serial port attachment ... and did not support USB 
plugplay.
It turned out that the vast majority of smartcard deployment problems in that 
time-frame
had to do with consumers trying to install serial port card readers, consumers
that couldn't find the serial port, serial port connections that conflicted with
something else, serial port conflicts, serial driver conflicts (large number of BSOD 
and consumers having to re-install their systems from scratch).


there was then a very complex and intricate series of negotiations getting
agreement to upgrade pc/sc to support USB plugplay (for starters, responses 
like why even bother since it had been proven already that smartcards weren't 
practical in the consumer marketplace ... ignoring for a moment that major
factor in the failures was the pc/sc serial port limitations) . 

There were also things like  alternative packaging ... USB keyboard with 
built-in smartcard reader, display,  and PIN-pad cut-out switch ... where 
keyboard incremental cost was more like $5  (but again, it required PC/SC 
to be upgraded to USB plugplay)


however, by that time, nearly every where you went, there were echos that it 
(some
deployment or another) had proven that smartcards were not practical in consumer 
environment. Note that it wasn't just consumer limited, there were instances where 
commercial  operations figured that it would be on the order of $500/PC to be able 
to handle PC/SC serial port smartcard reader attachments.


it was in the midst of these particular disasters that you also saw some of
the smartcard operating system projects being canceled (again the spreading
belief that smartcards were not practical in the consumer market place).
All of this can be pretty much put at the doors of the institutions failing
to understand some of the fundamental issues attempting to deploy serial-port
PC/SC in the PC market place of the time (and/or understand that large
driver behind doing the whole USB plugplay thing was the significant problem
and issues attempting to deal with the serial port implementation)

some number of past posts mentioning the whole PC/SC serial port problems
encountered with various attempts at smartcard deployments in the
PC/consumer marketplace
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's 
your private key
http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed 
Flowers
http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
http://www.garlic.com/~lynn/2002m.html#37 Convenient and secure eCommerce using 
POWF
http://www.garlic.com/~lynn/2002m.html#39 Convenient and secure eCommerce using 
POWF
http://www.garlic.com/~lynn/2003n.html#35 ftp authentication via smartcard

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The bank fraud blame game

2007-07-02 Thread Anne Lynn Wheeler

Florian Weimer wrote:


Oh really?

In Germany, early digital banking had no cryptographic protection at
all.  Integrity and confidentiality were inherited from the underlying
phone system.  There were no end-to-end digital signatures.  Nothing.
Just a one-time password for each transaction, but the password was
not tied to the transaction in any way.


This has the added benefit of eliminating the horribly complex
and vulnerable PKI-type of operation


Except that there aren't any attacks on the browser PKI.  That's part
of the reason why the certificate prices plummeted. 8-/



re:
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game

there had been lots of home banking with PCs starting in the 80s. these
were dial-up into private bank modem pools (both consumer and
business cash management). one of the trade-offs looking at
going to internet based operation is the enormous infrastructure
savings to financial institutions. 

in 1995, a presentation by one financial institutions figured that 
they were supporting something like 65 different software modem drivers 
(different modems, different operating systems, different platforms, 
etc). transitioning to internet met that they could eliminate all of 
that (lots of help desk, lots of serial port issues, lots of hardware

issues ... a much smaller precursor to the later smartcard PC/SC serial
port disaster).

they talked about what trade-offs were with any conversion to internet, 
the operating system vendors  and ISPs would  go to a common connectivity 
operation,  bearing the cost of all  the online connectivity ... amortized 
over a lot of online use (not just online  banking). This eliminated an
enormous cost for online banking. The downside was that the security issues 
significantly increased.


the dedicated financial applications have some similarities to
that earlier dial-up phone environment ... except they are using
something akin to a controlled SSL encrypted path (tunneled thru
the internet) where the remote PC application has preloaded information
about the financial institution's server (not needing traditional PKI 
trusted 3rd party certification authority to provide information about unknown

parties).

now with respect to weakness of using PKI for such purposes, i've contended 
in the past that the image/picture authentication helped increase the 
possibility that the consumer/client was dealing with valid financial 
institution (that they had previously registered the image/picture with).


in that sense, it can be viewed as countermeasure to common phishing attacks
... where clients are convinced to click on some field that takes their
browser to some webserver. Given that the attacker can supply both the
actual URL and the corresponding SSL digital certificate ... and majority
of clients have very weak binding between websites and the corresponding
URL (i.e. SSL PKI digital certificate is just checking that the webserver
contacted actually corresponds to the supplied URL)  then attackers
have found an enormous PKI weak link in the current way SSL is deployed 
(it relies on the user to provide the binding between the webserver

they think they are talking to and that webserver's URL ... where
SSL PKI is then only providing the binding between a URL and a webserver).

As a result, active MITM attacks have happened ... where consumer is 
convinced to click on a field purported to connect them to their

financial institution. The attack actually provides a URL to their
own webserver for which they have a valid SSL digital certificate ...
then they can transparently pass communication between the real
financial institution website and the consumer (with two different
SSL sessions connected at the attackers website) ... aka the image/picture
authentication stuff is to imcrease the sense of comfort a customer
would have that they are actually talking to their financial institution
(in view of all the SSL short-comings ... however, it doesn't actually
preclude the security attacks).

lots of past posts mentioning MITM-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

some specific past posts about MITM-attacks and bank site authentication
http://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private 
information to improve security
http://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL ... addenda 2
http://www.garlic.com/~lynn/aadsm26.htm#56 Threatwatch: MITB spotted: MITM over 
SSL from within the browser
http://www.garlic.com/~lynn/2007d.html#26 Securing financial transactions a 
high priority for 2007

part of this harks back to when were originally called 

Re: TPM, part 2

2007-07-02 Thread Anne Lynn Wheeler

Peter Gutmann wrote:

I have a friend who implemented a basic trusted-boot mechanism for a student
project, so we have evidence of at least one use of a TPM for TC, and I know
some folks at IBM Research were playing with one a few years ago, so that's at
least two users so far.  Anyone else?


as i've mentioned before ... we looked at somewhat similar hardware solution
(but much simpler) for the original acorn (ibm/pc code name), primarily as software piracy 
countermeasure  ... but the tamper resistant technology state of the art at the time was 
way too expensive ... and investigation was dropped. what was seen during
the 80s were things like those specially encoded floppy disks ... that had 
to be inserted when you started the application ... a couple past posts/references:

http://www.garlic.com/~lynn/2006p.html#41 Device Authentication - The answer to 
attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/aadsm27.htm#9 Enterprise Right Management vs. 
Traditional Encryption Tools
http://www.garlic.com/~lynn/2007m.html#20 Patents, Copyrights, Profits, Flex 
and Hercules

in the late 90s i would periodically chide the TPM folks about what
they were doing ... and at an assurance talk i gave in the trusted computing
track at intel developers forum (spring 2001), i chided the guy running
the effort (was sitting in the front row) that it was nice to see that 
over the previous couple yrs that TPM had started to look more  more

like the AADS chip strawman. his retort was something about it being
because I didn't have a committee of couple hundred people helping
me with (my) chip design. 


misc. past posts mentioning aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The bank fraud blame game

2007-07-02 Thread Anne Lynn Wheeler

Peter Gutmann wrote:

Smart cards are part of the problem set, not the solution set - they're just
an expensive and awkward distraction from solving the real problem.  What I
was suggesting (and have been for at least ten years :-) is a small external
single-function device (no need for an OS) that can't be compromised by
malware because there's no attack vector for the malware to get at it.


there is an interesting side story to this involving certification, common 
criteria,
protection profiles, etc.

possibly the majority of the smartcard protection profiles have to do with all 
the
problems allowing software/application to be loaded. on the other hand, you can
get a common criteria evaluation done on the basic chip ... w/o any application
loading ... and being able to show a much higher security level ... than might 
be
possible with any application actually loaded.

one of the problems i ran into getting higher than eal4+ for aads chip strawman
... was since everything was built into the silicon at manufacturing time, and 
nothing could be subsequently loaded ... all the crypto had to also be resident
in the silicon. 


one of the original objectives given for the aads chip strawman was being able
to do digital signature in contactless form factor within transit gate elapsed
time requirements (very low power and very fast) ... which eventually fell to
doing ec/dsa ... and i couldn't get an protection profile definition for ec/dsa
higher than eal4+.  similar chips ... w/o anything loaded had been able to
get eal5+ evaluation (or better) ... but since ec/dsa was built into the chip 
silicon,
it was only possible to get eal4+.

the other criteria for aads chip strawman was extremely aggressive cost 
reduction;
i had joked i was taking a $500 milspec part, cost reducing by 2-3 orders of
magnitude and at the same time increasing the integrity. part of the aggressive
cost reduction was choosing a single function (something you have 
authentication
via chip digital signature) that could be used in a broad range of applications 
...
and eliminate everything else.

misc. aads
http://www.garlic.com/~lynn/x959.html#aads

other posts in this thread:
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The bank fraud blame game

2007-07-01 Thread Anne Lynn Wheeler

Peter Gutmann wrote:

(The usage model is that you do the UI portion on the PC, but perform the
actual transaction on the external device, which has a two-line LCD display
for source and destination of transaction, amount, and purpose of the
transaction.  All communications enter and leave the device encrypted, with
the PC acting only as a proxy.  Bill of materials shouldn't be more than about
$20).


The decade or so old EU FINREAD standard is along this line ... sort
of modeled after point-of-sale terminal ... includes its own display and
pinpad (countermeasure to keyloggers). lots of past posts mentioning
EU FINREAD standard
http://www.garlic.com/~lynn/subintegrity.html#finread

the actual communications that enter and leave aren't required to
be encrypted ... the communication that enter are revalidated on
the display ... and the communication that exits is on the order
of an x9.59 transaction
http://www.garlic.com/~lynn/x959.html#x959

that are armored with digital signature (integrity and authentication)
... misc. posts mentioning naked transaction metaphor
http://www.garlic.com/~lynn/subintegrity.html#payments

old aads chip strawman from nearly decade ago postulated form factor
agnostic ... that could even be added to existing pda/cellphone for
a lot less and communicate wirelessly.
http://www.garlic.com/~lynn/x959.html#aads

in the mid-90s, the x9a10 financial standard working group had been given
the requirement to preserve the integrity of the financial infrastructure
for all retail payments. part of the detailed end-to-end threat and
vulnerability analysis was not only the end-point vulnerabilities
but also the large number of business processes that are giving rise
to security breaches and data breaches that have frequently made
the press. part of x9.59 transaction armoring was that all the
transaction information could be readily exposed and still not
be useful to attackers for performing fraudulent transactions.
This was countermeasure to all the breaches ... regardless of whether 
insiders or outsiders were involved ... it was recognized that

the transaction information had to be exposed in a large number
of business processes. Recognizing the impossibility of 
eliminating all such information exposure ... the x9.59 approach

was to eliminate the risk and fraud associated with such exposures
(i.e. impossible to eliminate all the breaches ... so eliminate
the risk and fraud associated with such breaches).

We had previously been called in to consult with small client/server
startup that wanted to do payment transactions on their server
http://www.garlic.com/~lynn/subnetwork.html#gateway

and had this technology called SSL that they wanted to use. The
issue in SSL was that it hid the information was moving across
the internet ... but left it totally exposed at all other
points (and in fact the numerous business processes required
such exposure). the x9.59 approach was then to try and eliminate
all such exposures ... but to eliminate the risks associated with
all exposure of the information (in effect, armoring the transaction
w/o requiring the information to be hidden as countermeasure to
fraudulent transactions).

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The bank fraud blame game

2007-07-01 Thread Anne Lynn Wheeler

re:
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game

slight addendas ...

1) EU finread
http://www.garlic.com/~lynn/subintegrity.html#finread
http://www.garlic.com/~lynn/subintegrity.html#assurance

one of the issues that we looked at early on in x9.59 standard ... somewhat 
related
to the EU finread ... was what proof did the financial institution have as to the 
integrity of the originating end-point (for doing risk assessment purposes). With

this motivation, X9.59 standard allowed for multiple digital signatures ... 
which
could include device authentication for finread-like devices (giving some 
assurance
as to the integrity of the originating end-point)

2) liability

there appears to be a lot more motivation for improving assurance in the online
banking scenario ... say, as opposed to e-commerce and retail payments. in the
e-commerce and retail payments ... financial institutions can charge off a lot
of fraud to the merchants (buried in things like interchange fees). in the 
online
banking scenario, merchants aren't part of the scene ... just leaving the 
consumer
and the financial institutions as the responsible parties.



misc. recent financial news items ...

Police arrest three suspects in credit card investigation (fraud)
http://www.redlandsdailyfacts.com/news/ci_6262066
ACH Fraud: Clearing House Aims To Clean House
http://www.banktechnews.com/article.html?id=200706260ZQVU91V
Mobile wallets to replace payment cards - report
http://www.finextra.com/fullstory.asp?id=17116
Debit Scam used 'parasite' pin pads
http://www.canada.com/vancouversun/story.html?id=773122d5-556f-4b50-87bc-2dc2ad205126k=24040
Shoppers 'easy prey' for debit card fraud
http://www.canada.com/vancouversun/news/story.html?id=8e460eed-1bab-4848-9f4c-eefbaecc5ab8

... 


in the early aads chip strawman (from the 90s)
http://www.garlic.com/~lynn/x959.html#aads

form-factor agnostic in user owned pda/cellphone were countermeasure
to foreign, unfamiliar POS-terminals that possibly were compromised
(i.e. paranoid consumers could have some responsible control over
their own devices ... as opposed to POS-terminals at random merchants)

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The bank fraud blame game

2007-07-01 Thread Anne Lynn Wheeler

Ian G wrote:
Unfortunately for the banks, there is a vast body of evidence that we 
knew and they knew or should have known that the PC was insecure [1].  
So, by fielding a system -- online commerce -- with a known weakness, 
they took responsibility for the fraud (from all places).


re:
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game

i.e. to large extent, the existence of the EU finread standard is proof
of attempt at countermeasures to the (known) PC integrity weaknesses.

the original electronic-commerce adopted the MOTO model 
(mail-order/telephone-order) which placed significant responsibility

on the merchant ... AND there was some presumption that physical
goods were involved, shipping to a known address. SSL was used as
compensating process, in theory, placing internet-order on level playing 
field with MOTO.


as electronic-commerce deviated more  more from the
MOTO-model and related assumptions ... there were increasing
risks and vulnerabilities.

one of the early problems ... in the electronic-commerce genre ...
was what to do with purely internet merchants. in the standard
MOTO model ... there is consumer financial institution, financially
responsible for the consumer and merchant financial institution,
financially responsible for merchants (with merchant interchange
fees largely underwriting the whole environment). 

merchant financial institutions tended to sponsor merchants where 
there were physical assets available for seizure ... equivalent to 
a month or two of credit card transactions. With every transaction

passing thru the sponsoring organization (or its agent), the merchant
financial institution had real-time knowledge of the outstanding exposure 
and risk (and was capable of cutting things off at a moments notice).
However, a lot of internet merchants were setting up as purely order 
fulfillment organizations with little in the way of physical assets.

In the early electronic commerce days there were some intense lobbying
that went on with the risk management departments in merchant 
financial institutions.


But as mentioned in previous post ... the move to online banking ...
removes the merchant completely from the picture (it is no longer
the electronic commerce MOTO-model) ... leaving just the end-user
and their financial institution as the responsible party.

In the mid-90s, financial institutions looking at the internet for
online, commercial banking and cash management (i.e. business 
equivalent to consumer online banking) were extremely conflicted 
... they frequently were almost insisting on their own appliance 
at the business (and low-end of SOHO at least overlaps high-end

of consumer online banking).

Various of the PC-based dedicated financial applications go to
quite some lengths to compensate for kind of vulnerabilities
typically associated with browser activity. For instance,
instead of relying on a trusted third party to certify that
some remote location really has a valid digital certificate,
they have a trusted repository of valid financial institutions.
This is somewhat the equivalent of the table of certification
authority trusted third parties built into browsers ... but
instead of table of certifying parties that can certify other
parties ... it is table of the actual financial institutions.
This has the added benefit of eliminating the horribly complex
and vulnerable PKI-type of operation (an don't rely on certification
of something totally unrelated to financial transaction operation,
but instead rely directly on known financial transaction operation).

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: A secure Internet requires a secure network protocol

2007-06-23 Thread Anne Lynn Wheeler

Alex Alten wrote:

SSL seems to be hanging by a thread, mainly the name to public key mapping
depends on how thorough the checking is done in to SSL vs application 
layers
inside of the web browser.  If this is hosed then unrestricted MITM is 
in the cards

sometime in the near future.


re:
http://www.garlic.com/~lynn/aadsm27.htm#29 A secure Internet requires a secure 
network protocol

i.e. we were called in to consult with this small client/server startup that 
wanted
to do payments on their server. they had this technology they called SSL ... 
and we
had to end-to-end process audits ... including walk-thru of some of these new 
business
entities that were calling themselves certification authorities.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

the fundamental SSL design point was that the user knows the relationship 
between a website
and a URL, the user entered that URL, and SSL would authenticate that the 
website that
the user *thot* they were talking to (from entering the URL), was in fact, the 
website
they were actually talking to.

these days, most users have no cognition about relationship between websites and URLs, 
they click on something in email and/or webpages. In this scenario, the attacker

is providing the URL and then the only thing that SSL is providing is 
authenticating
who the attacker is claiming to be (via the URL that the attacker provides).

the original SSL design point had implicit assumptions that users knew the 
relationship
between the website they thot they were talking to and URLs (and then SSL 
authenticated
the relationship between those known URLs and the website). For the most part 
those
assumptions are no longer valid ... which then breaks the security model and 
all bets
are off. With the potential attacker frequently providing both the URL and the 
website,
then the only thing SSL is providing is authenticating the website that the attacker 
claims to be (via the URL) is the website that they are (breaking original basic
assumption about SSL). This totally invalidates the assumption that SSL is proving 
that the website that the user *thot* they were talking to (via directly entering 
the URL) was, in fact, the website that they were talking to (aka the user has

no idea what website they are talking to ... because they no longer have the 
knowledge
about the relationship between websites they think they are talking to and the 
URLs
for those websites).

The (*URL*) name to key mapping isn't the problem ... that is the mechanics that 
SSL provided. The problem was that SSL security had implicit assumption that the

user knew the mapping between the website they think they talk to and the URL 
for
that website. In the current environment, that assumption is no longer valid,

So the basic, most common PKI infrastructures provide a trusted public key 
repository
(typically manufactured into browsers before they ship). Users are 
indoctrinated that
they can trust those public keys ... for the purposes of digitally signing 
digital
certificates. These digital certificates provide the binding between URL 
(actually
the domain names part of URL) and website public keys. It is imperative that the
user (knowledge) then provide the binding the website they think they are 
talking
to and the URL. That is the part that is missing in today's environment (and 
what
large numbers of attackers can leverage to slip thru the cracks).

The missing piece is trusted binding between who the user's think they are 
talking
to and the URL (or at least domain name). This could be accomplished by a 
separate trusted repository ... names that the end-user relates to and trusted 
binding between those names
and URLs. Attacker provided URLs that are clicked on ... then can be 
cross-checked
with things in that new trusted table (analogous to the way that the browser 
table
of certification authority public keys are trusted).

Then the issue is that if there is a trusted table mapping names to URLs (or at 
least
domain names) ... and a separate table of trusted public keys ... the whole 
thing
could be collapsed into a single table ... totally eliminating the level of
indirection provided by (redundant and superfluous) PKI and certification authorities 
... just add the public key to the trusted table of names  domain names (aka URLs).


The issue isn't so much that SSL is broken ... it is the implicit dependency on
users knowing the relationship between the website they think they were talking
to and the URL for those websites. Creating a user trusted table of website/urls
(analogous to the browser trusted table of certification authority public keys),
can make PKIs and certification authorities redundant and superfluous ... since
in whatever trusted process is used to maintain the trusted table of 
website/urls
... can also directly include the public key for those website/urls.

this is similar, but different to some of the domain name 

A secure Internet requires a secure network protocol

2007-06-22 Thread Anne Lynn Wheeler

A secure Internet requires a secure network protocol
http://www.infoworld.com/article/07/06/22/25OPsecadvise_1.html

from above:

Implementing -- and requiring -- stronger authentication and cryptography standards 
is the next step toward a new Internet


... snip ...

i would contend that majority of exploits are attacks on (vulnerable) end-points 
... not directly involving any actual network protocol or cryptography; this includes
(updated) variations on old-time social engineering ... which has some relation 
to authentication (between end-points) ... but on par with crooks using the telephone 
to call people and convince them of one thing or another (and then suggesting that 
encrypting the telephone call transmission would eliminate the problem).


one of the things seen in various of the SSL (authentication) vulnerabilities
... are attackers being able to (authenticate) prove who they claim to be
... however, who they claim to be for SSL authentication ... and who they
claim to be for their social engineering attacks ... may not be exactly the 
same.


As before, one of the largest class of attacks (not restricted to internet) are 
against information related to payment transactions and which (largely because of 
weak authentication in unrelated parts of the infrastructure) is then turned 
around and relatively easily used for fraudulent financial transactions. misc. 
past posts on the theme of naked transactions.

http://www.garlic.com/~lynn/subintegrity.html#payment


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Why self describing data formats:

2007-06-11 Thread Anne Lynn Wheeler

James A. Donald wrote:
Many protocols use some form of self describing data format, for example 
ASN.1, XML, S expressions, and bencoding.


Why?


gml (precursor to sgml, html, xml, etc) 
http://www.garlic.com/~lynn/subtopic.html#sgml


was invented at the science center in 1969 
http://www.garlic.com/~lynn/subtopic.html#545tech


... some recent (science center) topic drift/references in this post
http://www.garlic.com/~lynn/2007l.html#65 mainframe = superserver

G, M,  L were individuals at the science center ... so the
requirement was to come up with an acronym from the inventors initials

so some of the historical justification for the original markup language 
paradigm
can be found 


originally CMS had the script command for document formating ... using
dot format commands ... i.e. science center on 4th flr of 545 tech sq
doing virtual machines, cp67, cms, the internal network, etc ... and multics
on 5th flr of 545 tech sq ... draw from some common heritage to CTSS (and some
of the unix heritage traces back thru multics also to CTSS).

the original GML was sort of a combination of self-describing data (somewhat 
for
legal documents) 
http://www.sgmlsource.com/history/roots.htm

http://xml.coverpages.org//sgmlhist0.html

and document formating ... when GML tag formating was added to CMS script processing 
command. Later you find a big CMS installation at CERN ... and HTML drawing heritage 
from the waterloo clone of the CMS script command.

http://infomesh.net/html/history/early

first webserver in the states was at slac (a CERN sister location) ... another 
big vm/cms installation:

http://www.slac.stanford.edu/history/earlyweb/history.shtml

recent historical post/reference
http://www.garlic.com/~lynn/2007d.html#29 old tapes

last time i checked, w3c hdqtrs was around the corner from the old
science center location at 545 tech. sq.

before GML, the science center had an activity involving performance data
from the time-sharing service (originally using virtual machine cp67 service
and then transitioning to vm370) ... lots of system activity data was captured
every 5-10 minutes and then archived to tape ... starting in the mid-60s ...
by the mid-70s there was a decade of data spanning lots of different 
configurations,
workloads, etc. The original intention when the system activity data was being
archived was to include enuf self-describing information that the data could
be interpreted many yrs later. lots of past posts about using cp67vm370
for time-sharing services (both for internal corporate use and customers 
offering
commercial, online time-sharing services using the platform)
http://www.garlic.com/~lynn/subtopic.html#timeshare

lots of past posts about long term performance monitoring, workload profiling,
benchmarking and stuff leading up to things like capacity planning
http://www.garlic.com/~lynn/subtopic.html#benchmark

much later, you find things like ASN.1 encoding for handling interoperability
of network transmitted data between platforms that might have different
information representation conventions (like the whole little/big endian stuff).

one of the things swirling around digital signature activity in the mid-90s
was almost religious belief that digital certificate encoding mandated 
ASN.1. 

other digital signature operations that were less religious about PKI, 
x.509 identity digital certificates, etc ... were much less strict

about encoding technique for digitally signed operations ... included
certificateless digital signature infrastructures
http://www.garlic.com/~lynn/subpubkey.html#certless

One of the battles during the period between XML and ASN.1 proponents
during the period was that XML didn't provide for a deterministic encoding.
It really was somewhat a red herring on the digital certificate ... ASN.1
side ... since they were looking at always keeping things ASN.1 encoded
(not just for transmission) ... and only decoding when some specific 
information needed extraction.


On the other side was places like FSTC which was defining digitally
signed electronic check convention (with tranmission over ACH or ISO8583).
There was already a transmission standard ... which ASN.1 encoding would
severely bloat ... not to mention the horrible payload bloat that was
the result of any certificate-based infrastructure needing to append
redundand and superfluous digital certificates.

FSTC just defined appending a digital signature to existing payload.
The issue then became a deterministic encoding of the information
for when the digital signature was generated and verified. If you
temporarily encoded the payload as XML, generated the digital signature
... and then appended the digital signature to the standard (ACH or
ISO8583) payload ... the problem was that at the other end,
XML didn't provide a deterministic encoding methodology so that
the recipient could re-encode the payload and verify the digital
signature. So FSTC eventually defined some additional rules for
XML called 

Re: Why self describing data formats:

2007-06-11 Thread Anne Lynn Wheeler


re:
http://www.garlic.com/~lynn/aadsm27.htm#24 Why self describing data formats:

for other archaeological trivia ... later i transferred from the science center
to SJR and got to do some of the work on the original relational/sql 
implementation,
System/R.

a few years later, the L in GML also transferred to SJR and worked on 
relational,
included being involved in the development of of BLOBS (Binary Large OBjectS) 
for relational.


roll forward a few yrs to the acm (database) sigmod conference in san jose in
the early 90s. In one of the sessions, somebody raised the question about what
was all this X.500 and X.509 stuff going on in ISO ... and there was somebody
from the audience that explained how it was a bunch of networking engineers 
trying to re-invent 1960s database technology.


today ... you can periodically find heated online discussion about XML 
databases
and whether they compromise the purity of information integrity that you get
from the relational paradigm. lots of past posts mentioning various things about
system/r, relational database technology, etc
http://www.garlic.com/~lynn/subtopic.html#systemr


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: A crazy thought?

2007-06-11 Thread Anne Lynn Wheeler

re:
http://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?

for some other topic drift regarding certification authorities ... having been 
certification
authorities for digital certificates targeted at the (electronic but) 
offline market
... they encountered a number of issues in the mid-90s as the world was 
transitioning
to ubiquitous online operation ... the digital certificates were somewhat 
targeted for
relying parties ... dealing with total strangers (that they had no prior 
information
about) and had no timely mechanisms for directly contacting any authorities for
references regarding the stranger.

so one of the issues for x.509 identity certificates ... small x-over from this
other thread
http://www.garlic.com/~lynn/aadsm27.htm#25 Why self describing data formats

was to try and move out of the no-value market into the identity market ... aka 
...
as world transitioned to ubiquitous online operation ... the remaining offline
was no-value situations where the relying-party couldn't justify the cost of
maintaining information about the parties that they dealt with (aka something
analogous to browser cookies) and/or couldn't justify the cost of directly
contacting responsible agencies for information about the parties they were 
deailing
with.

now in this recent thread ... somewhat about some internet historical 
evolution

http://www.garlic.com/~lynn/2007l.html#67 nouns and adjectives
http://www.garlic.com/~lynn/2007l.html#68 nouns and adjectives
http://www.garlic.com/~lynn/2007l.html#69 nouns and adjectives
http://www.garlic.com/~lynn/2007l.html#70 nouns and adjectives

the last posts drifts into the subject of some of the recent churn around
identity activities ... also lengthy post on the subject here:
http://www.garlic.com/~lynn/aadsm27.htm#23 Identity resurges as a debate topic

the certification authorities were somewhat looking at increasing the
value of x.509 identity digital certificates (since there wasn't a lot
of future selling into the no-value market segment) by starting to
grossly overload the digital certificates with enormous amounts of
personal information.

now typically identity has been a authentication characteristic ...
adding potentially enormous amounts of personal information could be considered 
attempting to move into the authorization area ... where a relying-party might

be able to make a authorization, approval, and/or permission decision purely 
based
on the additional personal information in the digital certificate.

what was seen by the mid-90s was that many of the institutions were
starting to realize that x.509 identity digital certificates, grossly
overloaded with personal information represented significant privacy
and liability issues. what you saw then was a retrenchment to purely
authentication, relying-party-only digital certificate
http://www.garlic.com/~lynn/subpubkey.html#rpo

with the digital certificate containing little more than a record
locator (where all the necessary information was actually kept, even real-time,
and aggregated information ... which is difficult to achieve in a stale,
static digital certificate paradigm) and a public key ... note, however, 
we could  trivially show that in such situations the stale, static digital 
certificate was redundant and superfluous ... aka just add the public key to the

entity's record ... which already had all the personal, private and
other information necessary for authorization. in the payments
market segment ... this is somewhat separate from the fact that
the appended stale, static, redundant, and superfluous digital
certificates were causing a factor of 100 times payload and processing
bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat

one of the other problems faced by certification authorities attempting
to move identity digital certificates into the authorization market
segment was what (with loads of personal information), if any, liability 
were certification authorities going to accept with regard to authorization 
problems encountered by the relying-parties (depending on the digital

certificate personal information in their decision making process).

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: A crazy thought?

2007-06-11 Thread Anne Lynn Wheeler

Ian G wrote:
What you are suggesting is called Web of Trust (WoT). That's what the 
PGP world does, more or less, and I gather that the SPKI concept 
includes it, too.


However, x.509 does not support it.  There is no easy way to add 
multiple signatures to an x.509 certificate without running into support 
problems (that is, of course you can hack it in, but browsers won't 
understand it, and developers won't support you).


re:
http://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?
http://www.garlic.com/~lynn/aadsm27.htm#26 A crazy thought?
http://www.garlic.com/~lynn/aadsm27.htm#27 A crazy thought?

actually ... at a very fundamental level both PKI and PGP have nearly identical
business and implementation processes ... the difference is somewhat that the 
PKI operations tend to try and make out that their structure is more formal 
... and therefor should be more trusted.


Both implementations require that the relying-parties have some sort of local
trusted public key repository ... initially populated with some out-of-bad
process. In the SSL PKI scenario ... there tends to be a trusted public key
repository built into each browser distributed ... initially loaded with
possibly 40-50 public keys that you are told that you can trust. In the
web of trust scenario ... there tend to be some set of public keys
that are also trusted and have also been acquired in some out-of-band process.

In both scenarios ... the relying-party is expected to trust new public keys
that carry digital signatures ... where these digital signatures can be
verified with public keys from their local repository of (already) trusted
public keys (public keys that have typically been distributed/initialized
by some out-of-band process)

It isn't so much that the fundamental processes are different ... it
is more about how tightly controlled and cast in concrete the surrounding
pieces happen to be (aka formalized and not easily changed/adapted).

For totally other drift ... one of the places we came up with requirement
for multiple digital signatures was in the process for x9.59 financial
infrastructure for payment transactions ... i.e. in the mid-90s, the
x9a10 financial standard working group had been given the requirement
to preserve the integrity of the financial infrastructure for all retail
payments
http://www.garlic.com/~lynn/x959.html#x959

x9.59 actually doesn't specify the details of digital signature process ...
but defines the fields necessary for a payment transactions which require
authentication and integrity protection on end-to-end basis. one of the
scenarios is the authentication of the account holder with digital
signature (which also provides payment transaction integrity). one of
the trust issues was that their could be various kinds of exploits
at the originating environment (where the account holder's digital
signature and the transaction was otherwise valid). to increase the
trust (as indication of possible countermeasures against these additional
exploits/vulnerabilities) allowed for the originating environment to
also digitally sign the transaction (as a flavor of device authentication,
possibly a point-of-sale terminal or other kind of device that was
used to originate the transaction).

the FSTC electronic check work also allowed for multiple digital signatures
... representing the equivalent of requiring multiple co-signers on
business checks ... i.e. business checks that allow for single signer
if the amount is below some limit ... but requires additional co-signers
for larger amounts.

note that both in the FSTC electronic check and the X9.59 financial
standard scenario, there was some assumption that the basic transaction 
went via normal existing electronic payment networks ... with appended digital

signature(s) ... where the transaction might actually only be encoded
during just the digital signature generation and digital signature verification
processes. recent posts in the encoding thread:
http://www.garlic.com/~lynn/aadsm27.htm#24 Why self describing data formats:
http://www.garlic.com/~lynn/aadsm27.htm#25 Why self describing data formats:

also any additional appending of traditional digital certificates to such
operations could represent a factor of 100 times payload and processing
bloat.
http://www.garlic.com/~lynn/subpubkey.html#bloat

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: A crazy thought?

2007-06-09 Thread Anne Lynn Wheeler

Allen wrote:

Hi Gang,

In a class I was in today a statement was made that there is no way that 
anyone could present someone else's digital signature as their own 
because no one has has their private key to sign it with. This was in 
the context of a CA certificate which had it inside. I tried to suggest 
that there might be scenarios that could accomplish this but was told 
impossible. Not being totally clear on all the methods that bind the 
digital signature to an identity I let it be; however, the impossible 
mantra got me to thinking about it and wondering what vectors might make 
this possible.


CAs are certification authorities ... they certify some information they
have checked and issue digital certificates that represent that checking
... somewhat analogous to physical licenses, credentials, certificates.

most certification authorities aren't the authoritative agency for the
information that they certify ... for the most part they are simply
certifying that they have checked the information with whatever authoritative
agency is responsible for that information.

in that sense they are somewhat like notary ... i.e. if somebody has
done some identity theft and managed to obtain a valid driver's license
... the notary isn't held responsible ... they just notarize that
they checked a valid drivers license.

this is somewhat the catch-22 scenario in recent posts for ssl domain
name certification authorities
http://www.garlic.com/~lynn/subpubkey.html#catch22

where they are in something of a situation because big part of the
original justification for ssl domain name certificates involved
integrity issues with the domain name infrastructure ... however,
the domain name infrastructure is also the authoritative agency for
domain name owner information, which the ssl domain name certification
authority is dependent on as part of the integrity for certifying
ssl domain name information. Fixing integrity issues in the domain
name infrastructure ... improves the probability that correct
ssl domain name certification is being performed ... but fixing
integrity issues in the domain name infrastructure can also drastically
reduce justification for having ssl domain name certificates.

recent posts
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#21 307 digit number factored

in some cases, there is the possibility that the excessive attention
to the details of the cryptographic operations is pure obfuscation
that the rest of the end-to-end business processes may purely be
built on a house of cards.

for additional drift, some recent posts in related thread on digital certificates 
in another fora (including some possible infrastructure vulnerabilities

and systemic risks)
http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, 
dies
http://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007i.html#48 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007l.html#0 Re: John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007l.html#2 Re: John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007l.html#6 Re: John W. Backus, 82, Fortran 
developer, dies
http://www.garlic.com/~lynn/2007l.html#9 Re: John W. Backus, 82, Fortran 
developer, dies

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: 307 digit number factored

2007-05-26 Thread Anne Lynn Wheeler

StealthMonger wrote:

This would destroy the protection of one who depends on off-line,
message-based communication for self-defense.

Such a person may create and maintain a persistent pseudonym through
untraceable chains of random latency, anonymizing remailers which
thwart traffic analysis through mixing.

On-line, connection-based communication has low latency and can be
traced by traffic analysis.


re:
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored 



the credential/licensing/certificate paradigm was certification of strangers
who have never before communicated before ... and there was no timely, available
mechanism for providing information about the other party (aka the analogy
of letters of credit/introduction from sailing ship days and before).

parties with previous relationship can have available information about each
other based on prior relationship ... or strangers in first time communication
may have access to timely sources of information about the other party.

the issue wasn't that the offline stranger paradigm didn't exist ... it just
was a rapidly disappearing scenario ... aka digital certificates were somewhat
modeled after the sailing ship days letters of credit/introduction for
the early 80s offline email scenario for first time communication between
complete strangers ... dial-up local electronic post-office, exchange email,
hang-up ... and then potentially faced with first-time email from total 
stranger.

while digital certificate wasn't as high a quality information paradigm as
real-time, online ... in this particular scenario, it was better than the
alternative ... nothing.

the issue isn't eliminating digital certificates for the situations 
where they may be appropriate ... it is eliminating digital certificates
for uses where they are obsolete, never intended for, redundant and/or 
superfluous. For all the situations where digital certificates 
and PKI aren't applicable (or redundant and superfluous) they tend to represent

and extraneous and unnecessary business cost providing little or no added
value.

in the wake of some of the original stuff (w/SSL that is frequently no referred
to as electronic commerce) there was some investigations that looked at
adding digital certificate kinds of processing to existing real time payment
transactions
http://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored

 some of the comments was that adding such digital certificate processing 
would
bring payment transactions into the modern era. Our observation was that
reverting to an offline PKI, digital certificate processing paradigm would
set back real-time payment transactions several decades. That if you
were doing real-time payment transactions that online, timely processing
had significantly higher quality information processing ... real-time status
of public key onfile in the account record as well as aggregated information ...
recent payment transaction patterns, current balance and/or credit limit, etc.
It was in the wake of that series of exchanges that you saw OCSP work start
in IETF.

We observed that not only was the stale, static digital certificate addition
to real-time payment transactions redundant and superfluous ... that the typical
proposals of the period represented a factor of 100 times in payload size bloat
(enormous payload cost addition providing no added benefit) as well as the
redundant and superfluous digital certificate processing increased real-time
payment transaction processing by nearly a factor of 100 times. Misc. past
posts mentioning enormous redundant and superfluous stale static digital certificate 
added overhead

http://www.garlic.com/~lynn/subpubkey.html#bloat

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: dnssec?

2007-05-24 Thread Anne Lynn Wheeler

Anne  Lynn Wheeler wrote:
for other topic drift ... a recent post with some DNS related trivia ... 
more than a decade before DNS (about half-way down the post mentioning former 
MIT student)

http://www.garlic.com/~lynn/2007k.html#33 Even worse than UNIX

and for other topic drift, old email about online, real-time public key 
distribution (also predating DNS)

http://www.garlic.com/~lynn/2006w.html#email850515
in this post
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the 
network



and rfc editor announcement from today  my rfc index
http://www.garlic.com/~lynn/rfcietff.htm

http://www.garlic.com/~lynn/rfcindx16.htm#4871
4871 PS
   DomainKeys Identified Mail (DKIM) Signatures, Allman E., Callas J., Delany 
M., Fenton J., Libbey
M., Thomas M., 2007/05/22 (71pp) (.txt=166054) (Obsoletes 4870) (See Also 4870) 
(Refs 1847, 2045,
2047, 2440, 2821, 2822, 3447, 3490, 3766, 3833, 3851, 4033, 4234, 4686) (was
draft-ietf-dkim-base-10.txt) 


http://www.garlic.com/~lynn/rfcindx16.htm#4870
4870 -H
   Domain-Based Email Authentication Using Public Keys Advertised in the DNS 
(DomainKeys), Delany M.,
2007/05/22 (41pp) (.txt=87378) (Obsoleted by 4871) (See Also 4871) (Refs 1421, 
3833, 3851, 4648) (was
draft-delany-domainkeys-base-06.txt)

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: 307 digit number factored

2007-05-24 Thread Anne Lynn Wheeler

James A. Donald wrote:

The problem is organizational.  To get one decision
centrally made and imposed on everyone requires a
central body capable of making decisions and imposing
them on everyone, and before it can get that authority,
that central body usually has to raze Atlanta and burn
the crops, or inflict genocidal famine on the Ukraine.

The great strength and great weakness of the internet is
that it is an anarchy.  Anything that requires one
decision made for all, such as the domain name system,
got frozen when the internet became too large for
decision making by consensus, and is now extremely
difficult to change.

So to make changes, they have to be made incrementally:
You need a CA with the proposed policy and a deal with
several registrars, and that CA needs to get on the
Mozilla and IE list.  Nice selling point.  If you
register with, say OpenSRS, you would automatically get
an SSL cert. Unfortunately, the certification process
for a CA to get on the browser list seems to be somewhat
circular - to be a CA, you have to prove you are like
existing CAs, which is most easily done if you *are* an
existing CA, and have no intention of changing the way
you work.


re:
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored

... that could be the short term view ... as well as dealing
with established operation ... having been around since before
the current CA stuff started ... and somewhat involved in
helping get the current infrastructure established
(from the standpoint of its inception for what is now
called electronic commerce ... and having to do detailed
business process  technical walk thru and audit of the early
certification authority players) ... the issue is more how to 
replace something once it was established (i.e. the current 
infrastructure somewhat got fast uptake ... because it didn't have

alternative solutions to deal with).

re:
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?


somewhat topic drift with DNS related trivia ... more than a decade before
DNS
http://www.garlic.com/~lynn/2007k.html#33

and some old email (predating dns) suggesting online, realtime public key
server
http://www.garlic.com/~lynn/2006w.html#email810515
in this post
http://www.garlic.com/~lynn/2006w.htmL#12

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: 307 digit number factored

2007-05-24 Thread Anne Lynn Wheeler

re:
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored

part of the quick IETF uptake of SSL and VPN in the 94/95 time-frame was that 
there
really wasn't any serious competition. there was ipsec ... but it was 
end-to-end implementation
at low level ip-stack ... which were kernel implementations ... and then was 
faced
with the whole issue of distribution, installation and support of new kernels on
machines all around the world (from a variety of different vendors and different
operating systems).

SSL was almost a no-brainer ... since it just involved loading/installing a new
application (orders of magnitude easier than ipsec). lots of collected posts
mentioning SSL and/or SSL certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

in the same time-frame VPN was introduced at the gateway committee meeting at 
'94
San Jose IETF meeting. We had worked with the guy on and off since the late 70s 
and
he originally developed the technology for his own use ... between home and 
office;
actually both his wife and he worked for different technology companies ... he 
got
a leased line from the house to his office ... and her company got a circuit 
from
his office to their office. The issue was how to encrypt the wife's 
communication w/o
having it exposed to the husband and/or the husband's company.

sort of the state-of-the art had been link encryptors ... for a little topic 
drift ...
the internal corporate network had been larger than the arpanet/internet from 
just
about the beginning until possibly summer of '85. the internal network required
encryption on everything leaving the premise ... and in the mid-80s there were 
comments that the internal network had over half of all link encryptors in the world.

misc. past posts mentioning the internal network.
http://www.garlic.com/~lynn/subnetwork.html#internalnet

the requirement that led to VPN was how to carry separately encrypted streams over 
the same link. ipsec would have solved the problem ... but again was end-to-end

solution that required upgrading all the low-level ip-stacks ... which required
distribution, installation (and support) of new kernel. the VPN solution was
to handle the stream encryption/decryption in boundary routers (which could be
tunneled over other infrastructure).

my observation was this resulted in some amount of consternation in the ipsec 
faction ... which they somewhat resolved by starting to refer to VPN as lightweight

ipsec (and of course, everybody else could then refer to regular ipsec as
heavyweight ipsec).

the other problems was with various router vendors in the IETF. it was
sort of divided along the lines of the vendors that had enuf horse power in
their current boxes to implement and deploy VPN support ... and the other 
vendors
whos' products didn't have enuf processing power available to do the crypto
operations in support of VPN. This difference dragged out some of the VPN 
standardization
activity within IETF.

misc. past posts mentioning lightweight ipsec
http://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to 
PKI?
http://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took 
the wrong branch?
http://www.garlic.com/~lynn/aadsm25.htm#19 Hamiltonian path as protection 
against DOS
http://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec
http://www.garlic.com/~lynn/2007d.html#37 MAC and SSL
http://www.garlic.com/~lynn/2007g.html#63 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip

for other drift ... some of the people doing VPN implementations were using RSA
bsafe library ported to whatever processor they were using. Some number of these
put in effort to enhance the performance of bsafe library.

some of this was going on when we were in transition from working on the 
infrastructure
that is currently frequently referred to as electronic commerce and work in the
x9a10 financial standard committee. in that same time frame there were other
efforts looking at enhancing how payment transactions could be implemented and
deployed for the internet (as opposed to x9a10 standards work which had a requirement 
to have a standard that preserved the integrity of financial infrastructure for
ALL retail payments). 

One of these published some of their specification and from the specification I drew 
up a business operation profile and a public key operation profile. I then got the 
public key operation profile executed on a number of different platforms using the 
speeded up bsafe library (running four times faster) ... and reported the numbers 
back to the organization responsible for that 

Re: 307 digit number factored

2007-05-23 Thread Anne Lynn Wheeler

Ivan Krstić wrote:

That can't happen until we make sure you can trust DNS, which in turn
can't happen until we get a concrete proposal that has clearly defined
goals and isn't braindead. As has been amply pointed out, it's not clear
that DNSSEC will cut it anytime soon.


A big part of the issue is the domain name certification authority has to trust
the domain name infrastructure as to the true owner of the domain name ... when
they are processing a domain name certificate application for certification 
(i.e.
only the actual domain name owner on file with the domain name infrastructure 
should
be able to apply for domain name certifications).

The catch-22 is that the original idea behind domain name certificates were
because of integrity issues with the domain name infrastructure. However, the
domain name certification industry is dependent on the integrity of the domain
name infrastructure in their domain name certification process.

As a result they need to improve the integrity of the domain name infrastructure
because their dependency on the domain name infrastructure in their process of
certification. 


So one of the proposals (somewhat backed by the domain name certification 
authority
industry) is that domain name owners place a public key on file when they 
register
a domain name with the domain name infrastructure. They all future communication
with the domain name infrastructure can be digitally signed ... and the domain
name infrastructure verify the digital signature with the onfile public key.

This is intended to help improve the integrity of the domain name 
infrastructure.
However, it could also offer benefits to the domain name certification authority
industry. The domain name certification authority industry could also then start
requiring that domain name certification applications also be digitally signed.
The the domain name certification authority industry can do a real-time 
retrieval
of the on-file public key to verify the domain name certification application 
digital
signatures. This provides for turning a time-consuming, error-prone, and 
expensive
identification process into a much simpler, reliable, and less expensive 
authentication
process (enormous benefits for the domain name certification authority 
industry).

The issue is that if the domain name certification authority industry are 
somewhat
two fold:

1) the original justification for domain name certification involved integrity
issues with the domain name infrastructure. improving the integrity of the 
domain
name infrastructure would reduce the original justification for having domain
name certification

2) if the domain name certification authority industry could start relying
on real-time retrieval of public keys ... then possibly the rest of the world
could also ... eliminating the need for domain name infrastructure.

some collected catch-22 posts
http://www.garlic.com/~lynn/subpubkey.html#catch22

long ago and far away, we had been called in to consult with this small 
client/server
startup that wanted to do payment transactions and had this technology called
SSL. In addition to doing stuff about working out the payment transaction 
operation
we also had to do a lot of stuff with end-to-end business process investigation 
of
these new business operations called certification authorities. Since then,
this has frequently come to be referred to as electronic commerce. some old 
posts
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

and collection of posts mentioning payment processing and payment gateway
http://www.garlic.com/~lynn/subnetworkhtml#gateway

Now, the original SSL infrastructure was to verify that the URL that the
user entered (into the browser) corresponded to the website that the
browser was talking to (i.e. the website that the user thought they 
were talking to was the website they were actually talking to). However,

most electronic commerce sites fairly quickly found that SSL was costing
them something like 90percent of their thruput. The result was that most
websites transitioned to no longer using SSL for the initial user connection
but reserved just for the payment process (to hide the account number 
information). Now the user clicks on a button (provided by the webserver)

which generates a URL (provided by the webserver). Now instead of checking
the URL provided by the user against the webserver ... most use of SSL
now checks the URL provided by the webserver against the webserver (invalidating
the original SSL security assumptions). lots of past posts about ssl
digital certificate infrastructure
http://www.garlic.com/~lynn/subpubkey.html#sslcert

so it could be claimed that the way that the currently deployed SSL for the
electronic commerce infrastructure doesn't really cut it either ... it is 
somewhat
a case of the emperor's new clothes ... and the integrity of the domain
name infrastructure has to be improved in any case, since it is the 

Re: 307 digit number factored

2007-05-22 Thread Anne Lynn Wheeler

Victor Duchovni wrote:

The other issue is that sites will need multiple certs during any
transition from RSA to ECC, because the entire Internet won't upgrade
overnight. I am not expecting public CAs to cooperate by charging the
same price for two certs (RSA and ECC) for the same subject name(s),
this also may significantly impede migration.


in theory, certification authorities charge for the certification operations
that they perform ... and the certificate is just a representation of that
certification process.

somewhere over the yrs the term certification authority was truncated
to certificate authority ... along with some impression that 
certificates are being sold (as opposed to certification processes).


doing quicky web search of licensing and certification agencies ... it
looks like there is charge for replacing certificates/licenses ... but
nothing compared to the charge for the original certification process.

of course ... the whole licenses/credentials/certificates are an offline
world paradigm  licensing, credentialing, and certifications can be
validated with online, real-time operations ... obsoleting any requirement for
supporting offline methodologies.

it would be really great to make it an excuse to move away from offline
paradigm to real online operation ... getting totally rid of the need for
domain name certificates ... DNS serving up both ip-addresses and public
keys in single operation.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: 0wned .gov machines (was Re: Russian cyberwar against Estonia?)

2007-05-20 Thread Anne Lynn Wheeler

Ivan Krstić wrote:

I think it's anything but surprising. There's only so much you can do to
significantly improve systems security if you're unwilling to break
backwards compatibility -- many of the fundamental premises of desktop
security are fatally flawed, chief among them the idea that all programs
execute with the full privileges of the executing user.


part of this is that many of the basic platforms providing internet connectivity
evolved from disconnected/unconnected desk/table top environment ... with
lots of applications assuming that they had full  free access to all resources.

attempting to leverage the same platforms for connectivity to extremely 
hostility
and anarchy of the internet creates diametrically opposing requirements.

one countermeasure from the 60s is to use a dynamically created (padded cell)
virtual machine for internet connectivity ... with limited scope and accesses.
then when the session completes ... the environment is collapsed and everything
is discarded. 

while the native system operation may have little or no defenses against the hostile 
internet ... the padded cell virtual machine environment is used to bound the scope 
of any penetration ... somewhat analogous to air gapping.


recent post:
http://www.garlic.com/~lynn/2007k.html#48

somewhat older reference:
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Enterprise Right Management vs. Traditional Encryption Tools

2007-05-14 Thread Anne Lynn Wheeler

Jason Holt wrote:
ERM/DRM/TPM are such poorly defined and implemented products that people 
have started referring to a DRM fairy who people assume will wave her 
wand and solve whatever problem is at hand.  I used to try to draw out 
the mentioner's claims into a concrete proposal that everyone could 
objectively examine, but the conversation rarely progressed that far.  
So now I think that, as with other crypto proposals, the onus should now 
be on the proposer to clearly delineate what they're proposing and 
convince us that it's complete and correct, rather than us nodding our 
heads or lashing out at what we assume it means.


somewhat aside ... there was an effort in the very early days of the PC
to look at (hardware) countermeasures to software (and other) piracy
(I don't remember whether i was involved shortly before or after the 
actual announcement of the PC).


starting with 370, the mainframes had unique processor identifications
and licensed software was configured for the specific processor. this
may have been relatively easy to defeat ... but the numbers and costs
involved somewhat created a barrier. It was sufficient to show that
some (illegal) action had to have been taken in order to successfully
prosecute.

because the costs and numbers involved with the PC were so significantly 
different, individual prosecution was harder to justify ... and so the hardware

countermeasures needed to be much more robust. a problem with the investigation
at the time was that tamper-evident technologies were way too expensive
which contributed to the investigation being shelved.

somewhat in the wake of that ... there were various methods like 
specially encoded floppy disks as countermeasure to piracy (i.e.

the floppy disks were not trivially duplicated by normal means).

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Public key encrypt-then-sign or sign-then-encrypt?

2007-05-09 Thread Anne Lynn Wheeler

Travis H. wrote:

This reminds me a bit of a suggestion I once heard for protocol
designers that the messages of the various steps of the protocol
include a step number or something like it to prevent cut-and-paste
attacks (presumably each message has some redundancy to protect the
integrity/authenticity as well, like a running hash covering all the
previous messages (in this direction)).

I wonder if something similar couldn't be done with digital
signatures, where the input is padded with data that indicates the
semantics of the signature; not unlike the forms which say by signing
here I agree that...

This also makes it very difficult for the opponent to do any kind
of chosen-plaintext trickery since the plaintext will be framed
with this data that the opponent does not control, but that is
also true with other padding options and such.


re:
http://www.garlic.com/~lynn/aadsm26.htm#65 Public key encrypt-then-sign or 
sign-then-encrypt?

some aspects of this was discussed in old dual-use attack thread ... it possibly 
isn't enuf to encapsulate all scenarios where the person intends to use the digital signature

in manner analogous to human signature (indicating intent, having read, 
understood,
authorizes, agrees, and/or approves)  then if there is ever a digital 
signature
applied for pure authentication purposes ... say random data from a server (as
countermeasure to replay attacks) ... then all such signed data should always 
also
be bracketed by disclaimer saying that such signatures are in no way met to 
imply
agreeing, approving, and/or authorization any message content.

the problem is that digital signatures are an authentication and integrity 
mechanism,
and except for possible semantic confusion resulting from both digital 
signature
and human signature containing the same word (signature) ... there is no
relationship. a danger of any mis-use of digital signatures as representing
human signatures  ... is if they are also used for authentication ... where the
human doesn't actually physically examine and understand every bit that a
signature might be applied to. if the human doesn't actually physical examine
and understand every bit that they might apply a signature too ... then it
becomes a requirement that all such (signed and unexamined) bits are wrapped 
with strong disclaimer about any existence of a digital signature is not met to 
imply read, understood, approves, agrees, and/or authorizes.


... aka any random data not examined, but signed ... could in fact contain 
padding
and comments about aggreement ... to appear as if the signer actually wrapped
it (instead of the attacker).

lots of past posts discussing signatures ... included having been called in
to help word-smith the cal. state electronic signature legislation.
http://www.garlic.com/~lynn/subpubkey.html#signature

related and slightly facetious posting here:
http://www.garlic.com/~lynn/aadsm26.htm#69 survey of RFC S/MIME signature 
handling
as part of this thread
http://www.garlic.com/~lynn/aadsm26.htm#67 survey of RFC S/MIME signature 
handling

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


  1   2   3   4   5   >