Re: Who's afraid of Mallory Wolf?

[Anne & Lynn Wheeler]

At 12:09 PM 3/25/2003 -0800, bear wrote:
ISP's don't want to support encrypted links
because it raises their CPU costs.  And mail
clients generally aren't intelligently designed
to handle encrypted email which the mail servers
could just "pass through without decrypting and
encrypting".


circa '95  there were comments that ISP's didn't want to verify 
from/spoofed packet addresses on DHCP modem connections because it 
increased their router cpu costs (actually one of the most common routers 
didn't have enuf processor power to implement even trivial packet filtering 
on modem lines).

http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic 
rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic 
rules, traffic signs, traffic lights  and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic 
rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic 
rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic 
rules, traffic signs, traffic lights and traffic enforcement

now there is the observation in this thread (or the previous thread) that 
many websites use SSL very sparingly because it cuts their web traffic 
capacity by 80-90 percent (http vis-a-vis https given the same hardware).

Typical sequence is that person clicks-on/types something and goes to a 
site with straight HTTP, they shop for a while ... until they are ready to 
check-out, they then click on the "check-out" button. That button supplies 
a URL that sends them off to a HTTPS site (aka the user didn't actually 
originated the HTTPS url) ... where all the payment information is 
provided. Now since the client/consumer never provided the actual HTTPS 
sequence   but it was provided for them by a webpage at the HTTP site 
they were shopping at  it is presumably trivial for the HTTP site that 
they are shopping at to make sure that the HTTPS URL domain that clients 
are sent to  matches the certificate domain at that site (and a lot of 
shopping URLs have a lot of  appended history so that it is relatively 
easily contrived that the consumer doesn't notice the domain name of the 
"check-out/payment" page).

A lot of the requirement for encryption is end-to-end ... or at least 
VPN-like  so encrypted packets should mostly be transparent to 
operations in their ISP roles. This isn't as true on the web-hosting side 
of the house ... where SSL or similar encryption activity can represent 
significant additional CPU processing load.
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Who's afraid of Mallory Wolf?

[Anne & Lynn Wheeler]

At 12:17 AM 3/25/2003 -0500, Ian Grigg wrote:
I'd say, SSL with the cert protection is the
strongest link in the chain.  In fact, it's
ludicrously strong.  It's like a Chubb vault
lock on a screen door.  If we were getting
physical here, the door wouldn't be strong
enough to hold up the lock.
except the certification authorities ... when doing the certification of 
who owns a domain name  still asks the domain name infrastructure as to 
who really owns the domain name  when they get a request for a SSL 
domain name certificate. SSL domain name certificate request  after a 
domain name hijack still is possible (aka a chubb vault lock with a 
possible backdoor).

the other scenario that has been raised before is that the browsers treat 
all certification authorities the same  aka if the signature on the 
certificate can be verified with any of the public keys in a browser's 
public key table ... it is trusted. in effect, possibly 20-40 different 
manufactures of chubb vault locks  with a wide range of business 
process controls ... and all having the same possible backdoor. 
Furthermore, the consumer doesn't get to choose which chubb lock is being 
chosen.
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Who's afraid of Mallory Wolf?

[Anne & Lynn Wheeler]

At 10:02 PM 3/24/2003 +, David Wagner wrote:
You could take your argument even further and
ask whether any crypto was needed at all.
After all, most attacks have worked by compromising
the endpoint, not by sniffing network traffic.
I'll let you decide whether to count this as a
success story for SSL, or as indication that the
crypto wasn't needed in the first place.
(I'm a little skeptical of this argument, by the
way, but hey, if we're playing devil's advocate,
why not aim high?)
I assert that there may be more sites that transmit credit card numbers w/o 
crypto, as sites that use SSL (although transaction rates are highly skewed 
so they even if it were ten times the number of sites, it might represent 
fewer actual transmissions). I don't have actual numbers, but I am aware of 
significant number of sites. However, I would contend that harvesting 
numbers from end-point merchant files has significantly higher return (ROI, 
expected results for the effort) than any sort of network evesdropping ... 
and that it is practically impossible to provide the necessary armoring as 
countermeasure for this vulnerability; end point attacks by either insider 
and outsider (historically, insider attacks on financial infrastructure 
have represented vast majority of incidents. While it may be possible to do 
a single armored site  it isn't practical to do a million such sites 
(for one thing, people make too many mistakes) ... as per previous ref to 
security proportional to risk (and the merchant file risk is proportional 
to the credit limits of the accounts, not the specific merchant transaction).

I would expect that network evesdropping  would be employed where 
vulnerability was something other than kind of fraud do'able by attacking 
the end-point merchant file. Note however, skimming (various kinds of 
electronic & non-electronic recording) does go on in the physical world. 
Part of the issue may be that the target object (account number) has much 
lower occurance in general internet traffic (physical world skimming 
involves traffic that is almost solely account numbers). If you just have 
to skim, there are some number of points that are much more target rich 
environments (better fraud ROI) than internet traffic.

There is some phrase that if the only thing you know how to use is a 
hammer, then every solution may involve a nail.

The fundamental problem with account numbers is that they are effectively a 
kind of shared-secret  acquiring/harvesting the numbers enables fraud. 
There are significant number of business processes that require the 
availability of the account numbers. This is one of the reasons for the 
end-point merchant files and also why "SET" (with significantly more 
complex crypto infrastructure and essentially only, also addressing data 
in-flight) offered very little additional over what my wife and I were 
involved with setting up the original SSL for e-commerce.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

The point of x9.59 wasn't to add even more layers of crypto and information 
hiding to protect these shared-secrets  but to change the business 
model so that the account numbers were no longer shared-secrets. X9.59 uses 
simple digital signature for authenticated payment transactions and a 
business rule that account numbers used in x9.59 transactions can't be used 
in non-authenticated payment transactions.
http://www.garlic.com/~lynn/index.html#x959
aka just by evesdropping an x9.59 transactions or harvesting account 
numbers used in x9.59 transactions doesn't enable a crook to initiate a 
fraudulent payment transaction.
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Armoring websites

[Anne & Lynn Wheeler]

ref:
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#2 Who's afraid of Mallory Wolf? 
(addenda)

here is discussion of armoring websites with respect to security 
proportional to what is at risk
http://www.garlic.com/~lynn/2001h.html#61 net banking, is it safe???
http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? 
... security proportional to risk

random refs to hardened sites:
http://www.garlic.com/~lynn/aadsm2.htm#risk another characteristic of 
online validation.
http://www.garlic.com/~lynn/2001.html#33 Where do the filesystem and RAID 
system belong?
http://www.garlic.com/~lynn/2002.html#44 Calculating a Gigalapse
http://www.garlic.com/~lynn/2002m.html#5 Dumb Question - Hardend Site ?
http://www.garlic.com/~lynn/2002m.html#6 Dumb Question - Hardend Site ?
http://www.garlic.com/~lynn/2002o.html#14 Home mainframes
http://www.garlic.com/~lynn/2003c.html#52 diffence between itanium and alpha
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Who's afraid of Mallory Wolf? (addenda)

[Anne & Lynn Wheeler]

 and while I don't know of any internet-based evesdropping for account 
number harvesting  there are numerous reports of skimming in the 
physical world  harvesting of account numbers by all sorts of 
techniques. These include things like video cameras by crooks trained 
on  various kinds of POS and other terminals.

misc. skimming references:
http://www.garlic.com/~lynn/aadsm12.htm#40 In Brief: Anti-'Skimming' 
Guidelines Coming
http://www.garlic.com/~lynn/aadsm12.htm#57 eBay Customers Targetted by 
Credit Card Scam
http://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aadsm6.htm#pcards3 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aepay10.htm#3 High-tech Thieves Snatch Data 
From ATMs (including PINs)
http://www.garlic.com/~lynn/aepay10.htm#41 ATM Scams - Whose Liability Is 
It, Anyway?
http://www.garlic.com/~lynn/aepay10.htm#44 Credit Card Skimming Rising In 
The US
http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card 
fraud"
http://www.garlic.com/~lynn/aepay9.htm#skim High-tech Thieves Snatch Data 
From ATMs (including PINs)
http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
http://www.garlic.com/~lynn/2002i.html#74 A Lesson In Security
http://www.garlic.com/~lynn/2002j.html#60 How to map a user account to a 
digital cert?
http://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in 
abscense of client certificates
http://www.garlic.com/~lynn/2002l.html#20 Backdoor in AES ?
http://www.garlic.com/~lynn/2002m.html#36 (OT) acceptance of technology, 
was: Convenient and secure
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Who's afraid of Mallory Wolf?

[Anne & Lynn Wheeler]

 there are potentially millions, 2) human mistake is 
frequent/common vulnerability, 3) still leaves insiders as threat.

other parts of security proportional to risk thread:
http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk 
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk 
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk 
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#24 Security Proportional to Risk 
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#25 Security Proportional to Risk 
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#28 Security Proportional to Risk 
(was: IBM Mainframe at home)
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: How effective is open source crypto? (aads addenda)

[Anne & Lynn Wheeler]

we did something similar for AADS PPP Radius
http://www.garlic.com/~lynn/index.html#aads
AADS radius example
http://www.asuretee.com/
... with FIPS186-2, x9.62, ecdsa digital signature authentication on 
sourceforce 
http://ecdsainterface.sourceforge.net/

radius digital signature protocol has replay challenge.

so adding radius option to webserver client authentication stub 
(infrastructure can share common administration client authentication 
across all of its environments). then client clicks on https client 
authentication, generates secret random key, encrypts request for client 
authentication with random key, encrypts random key with server public key, 
sends off single transmission. Server responds with radius connect request 
 which includes replay challenge value as part of message (encrypted 
with random key). Client responds with digital signature on the server 
radius message (and some of its own data, encrypted with random key).

Basically use the same packet sequence as in transaction w/o replay 
challenge ... since higher level protocol contains replay challenge.  Then 
can use same packet sequence for webserver TLS and encrypted PPP (and works 
as VPN; possibly can define also as encrypted TCP)  along with the same 
client authentication infrastructure

Infrastructure can use the same administration (RADIUS) infrastructure for 
all client authentication  say enterprise with both extranet 
connections as well as webserver  or ISP that also supplies webhosting. 
The same administrative operation can be used to support client 
authentication at the PPP level as well as at the webserver level.

The same packet exchange sequence is used for both PPP level encryption 
with client authentication as well as TLS for webserver level encryption 
with client authentication.

The higher level application can decide whether it already has sufficient 
replay/repeat resistance or request replay/repeat resistance from lower 
level protocol.

So regardless of TLS, PPP, or TCP, client authentication (using same packet 
sequence as transaction, w/o lower level replay challenge):

1) client picks up server public key and encryption options (from cache or DNS)

2) client sends of radius client authentication, encrypted with random 
secret key, encrypted with server public key ...

3) server lower level protocol handles the decryption of the random secret 
key and the decryption of the client request (which happens to be radius 
client authentication  but could be any other kind of transaction 
request) and passes up the decrypted client request

4) server higher level protocol (radius client authentication) responds 
with radius replay challenge

5) client gets the replay challenge, adds some stuff, digitally signs it 
and responds

6) server higher level radius client authentication protocol appropriately 
processes

Same server public key initial connect code works at TLS, PPP, and possibly 
TCP protocol levels. The same server public key initial connect code 
supports both lower-level replay challenge and no replay challenge.

Same radius client authentication works at TLS, PPP, and possibly TCP 
protocol levels. Same client administrative processes works across the 
whole environment.

aka  the radius client authentication protocol is just another example 
(like the purchasse order example) of the higher level protocol having its 
own replay/repeat handling infrastructure (whether it is something like log 
checking or its own replay challenge).

--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: How effective is open source crypto? (bad form)

[Anne & Lynn Wheeler]

At 09:30 AM 3/16/2003 -0800, Eric Rescorla wrote:

Correct.

It's considered bad form to design systems which have known replay
attacks when it's just as easy to design systems which don't.
If there were some overriding reason why it was impractical
to mount a defense, then it might be worth living with a replay
attack. However, since it would have only a very minimal effect
on offered load to the network and--in most cases--only a marginal
effect on latency, it's not worth doing.
-Ekr

--
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/
so, lets look at the alternatives for servers that are worried about server 
replay attacks:

client has public key & crypto-preferred info (dns or cached), generates 
random secret key, encrypts request, encrypts random secret key, single 
transmission

server gets request ... application has opened the connection with or w/o 
server replay attack. if the application, higher level protocol has its own 
repeat checking  it has opened the connection w/o server replay attack. 
and the server sends the request up the stack to the application. If the 
application has opened the connection with server replay attack, the 
protocol sends back some random data (aka its own secret)... that happens 
to be encrypted with the random key.

The client is expecting either the actual response or the replay attack 
check. If the client gets the actual response, everything is done. If the 
clients gets back the replay attack check  it combines it with 
something  and returns to the server.

The difference is basic two packet exchange (within setup/teardown packet 
exchange overhead) plus an additional replay prevention two packet exchange 
(if the higher level protocol doesn't have its own repeat handling 
protocol). The decision as to whether it is two packet exchange or four 
packet exchange is not made by client ... nor the server ... but by the 
server application.

Simple example for e-commerce is sending a P.O. along with payment 
authorization ... the transmitted P.O. form is guaranteed to have a unique 
identifier. The P.O. processing system has logic for handling repeat POs 
... for numerous reasons (not limited to replay attacks).

Single round-trip transaction:

ClientHello/Trans->
<- ServerResponse/Finish
Transaction w/replay challenge:

ClientHello/Trans->
<-Server replay challenge
ClientResp->
<-ServerResponse/Finish
Now, ClientHello/Trans can indicate whether the client is expecting a 
single round-trip or additional data.

Also, the ServerResponse can indicate whether it is a piggy-backed finish 
or not.

So, the vulnerability analysis is what is the object of the replay attack 
and what needs to be protected. I would contend that the object of the 
replay attack isn't directly the protocol, server, or the system  but 
the specific server application. Problem of course, is that with generic 
webserver (making the connection) there might be a couple levels of 
indirection between the webserver specifying the connection parameters and 
the actual server application (leading to webservers always specifying 
replay challenge option).
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
  
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: How effective is open source crypto? (addenda)

[Anne & Lynn Wheeler]

... small side-note  part of the x9.59 work for all payments in all 
environments  was that the transaction system needed to be resilient to 
repeats and be done in a single round-trip (as opposed to the transport).

there needed to be transaction resiliency with respect to single round trip 
with something like email that might not happen in strictly real-time 
(extremely long round-trip delays).

Real-world systems have been known to have glitches ... order/transaction 
generation that accidentally repeats (regardless of whether or not 
transport is catching replay attacks).
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: How effective is open source crypto?

[Anne & Lynn Wheeler]

At 08:40 AM 3/16/2003 -0800, Eric Rescorla wrote:
You still need a round trip in order to prevent replay attacks. The
fastest that things can be while still preserving the security
properties of TLS is:
ClientHello   ->
ClientKeyExchange ->
Finished  ->
  <-  ServerHello
  <-  Finished
Data  ->
See Boneh and Schacham's "Fast-Track SSL" paper in Proc.ISOC NDSS 2002
for a description of a scheme where the client caches the server's
parameters for future use, which is essentially isomorphic
to having the keys in the DNS as far as the SSL portion goes.
In any case, the optimization you describe provides almost no
performance improvement for the server because the load on the server
derives almost entirely from the cryptography, not from transmitting
the ServerHello [0]. What it does is provide reduced latency,
but this is only of interest to the client, not the server,
and really only matters on very constrained links.
-Ekr

[0] With the exception of the ephemeral modes, but they're simply
impossible in the scheme you describe.
Sorry, there were two pieces being discussed.

The part about SSL being a burden/load on servers 

and the shorten SSL description taken from another discussion. The shorten 
SSL description was (in fact) from a discussion of the round-trips and 
latency ... not particularly burden on the server. In the original 
discussion there was mention about HTTP requires TCP setup/teardown which 
is minimum seven packet exchange  and any HTTPS chatter is in addition 
to that. VMTP, from rfc1045 is minimum five packet exchange, and XTP is 
minimum three packet exchange. A cached/dns SSL is still minimum seven 
packet exchange done over TCP (although XTP would reduce that to three 
packet exchange).

So what kind of replay attack is there. Looking at purely e-commerce ... 
there is no client authentication. Also, since the client always chooses a 
new, random key  there is no replay attack on the client ... since the 
client always sends something new (random key) every time. That just leaves 
replay attacks on the server (repeatedly sending the same encrypted data).

As follow-up to doing the original e-commerce stuff ... we then went on to 
look at existing vulnerabilities and solutions  and (at least) the 
payment system has other methods already in place with regard to getting 
duplicate transaction  aka standards body for all payments (credit, 
debit, stored-value, etc) in all (electronic) environments (internet, 
point-of-sale, self-serve, face-to-face, etc), X9.59
http://www.garlic.com/~lynn/index.html#x959 (standard)
http://www.garlic.com/~lynn/index.html#aadsnacha (debit/atm network pilot)

Replay for simple information retrieval isn't particularly serious except 
as DOS  but serious DOS can be done whether flooding is done with 
encrypted packets or non-encrypted packets. Another replay attack is 
transaction based ... where each transaction represents something like 
performing real world transaction (send a shirt and debit account). If it 
actually involves payment ... the payment infrastructure has provisions in 
place to handle repeat/replay and will reject. So primarily what is left 
 are simple transaction oriented infrastructures that don't have their 
own mechanism for detecting replay/repeats and are relying on SSL.

I would also contend that this is significantly smaller exposure than 
self-signed certificates.



--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: How effective is open source crypto?

[Anne & Lynn Wheeler]

having worked on some of the early e-commerce/certificate stuff ... recent ref:
http://www.garlic.com/~lynn/aadsm13.htm#25 Certificate Policies (addenda)
the assertion is that basic ssl domain name certificate is so that the 
browser can check the domain name from the url typed in against the domain 
name from the presented (trusted) certificate ... and have some confidence 
that the browser is really talking to the server that it thinks it is 
talking to (based on some trust in the issuing certification authority). in 
that context ... self-certification is somewhat superfluous ... if you 
trust the site to be who they claim to be ... then you shouldn't even have 
to bother to check. that eliminates having to have a certificate at all ... 
just transmit a public key

so slight step up from MITM-attacks with self-signed certificates would be 
to register your public key at the same time you register the domain. 
browsers get the server's public key from dns at the same time it gets the 
ip-address (dns already supports binding of generalized information to 
domain ... more than simple ip-address). this is my long, repetitive 
argument about ssl domain name certification 
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

i believe a lot of the non-commercial sites have forgone SSL certificates 
 because of the cost and bother.

some number of the commercial sites that utilize SSL certificates  only 
do it as part of financial transaction (and lots of them  when it is 
time to "check-out"  actually transfer to a 3rd party service site that 
specializes in SSL encruyption and payments). The claim by many for some 
time  is that given the same exact hardware  they can do 5-6 times 
as many non-SSL (non-encrypted) HTTP transactions as they can do SSL 
(encrypted) HTTPS transactions  aka they claim 80 to 90 percent hit to 
the number of transactions that can be done switching from HTTP to HTTPS.

a short version of the SSL server domain name certificate is worry about 
attacks on the domain name infrastructure that can route somebody to a 
different server. so SSL certificate is checked against to see if the 
browser is likely talking to the server they think they are talking to. the 
problem is that if somebody applies for a SSL server domain name 
certificate  the CA (certification authority) has to check with the 
authoritative agency for domain names  to validate the applicants 
domain name ownership. The authoritative agency for domain names is the 
domain name infrastructure that has all the integrity concerns giving rise 
for the need for SSL domain name certificates. So there is a proposal for 
improving the integrity of the domain name infrastructure (in part backed 
by the CA industry ... since the CA industry is dependent on the integrity 
of the domain name infrastructure for the integrity of the certificate of 
the certificates) which includes somebody registering a public key at the 
same time at a domain name. So we are in catch-22 

1) improving the overall integrity of the domain name infrastructure 
mitigates a lot of the justification for having SSL domain name 
certificates (sort of a catch-22 for the CA industry).

2) registering a public key at the same time as domain name infrastructure 
... implies that the public key can be served up from the domain name 
infrastructure (at the same time as the ip-address  eliminating all 
need for certificates).

There is a description of doing an SSL transaction in single round trip. 
The browser contacts the domain name system and gets back in single 
transmission the 1) public key, 2) preferred server SSL parameters, 3) 
ip-address. The browser selects the SSL parameters, generates a random 
secret key, encrypts the HTTP request with the random secret key, encrypts 
the random secret key with the public key ... and sends off the whole thing 
in a single transmission  eliminating all of the SSL protocol 
back&forth setup chatter. The browser had to contact the domain name system 
in any case to get the ip-address  the change allows the browser to get 
back the rest of the information in the same transmission.



--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Encryption of data in smart cards

[Anne & Lynn Wheeler]

At 01:13 PM 3/13/2003 -0500, John Kelsey wrote:
At 11:08 PM 3/12/03 +0100, Krister Walfridsson wrote:

...
This is not completely true -- I have seen some high-end cards that use
the PIN code entered by the user as the encryption key.  And it is quite
easy to do similar things on Java cards...
With any kind of reasonable PIN length, though, this isn't all that 
helpful, because of the small set of possible PINs.  And smartcards don't 
generally have a lot of processing power, so making the PIN->key mapping 
expensive doesn't help much, either.

   /Krister
--John Kelsey, [EMAIL PROTECTED]
note however, that PIN could be possibly in infrastructure with real secret 
key and encryption done with derived key. the derived key one-way function 
is attempting to protect the infrastructure-wide secret key from brute 
force key search on specific piece of data. The issue is how many bits in a 
PIN is required to protect the secret key in a one-way function (involving 
the secret key and the PIN). A simple derived key is sufficient using the 
secret key and public account number. Adding a (privately known, card 
specific) PIN to such a derived key function:

1) doesn't increase the ease of attack on the secret key

2) doesn't affect brute force attack on the derived key

3) makes it harder to use a lost/stolen card
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Encryption of data in smart cards

[Anne & Lynn Wheeler]

there are a large number of different kinds of cards  however the most 
prevalent smartcards (in terms of numbers deployed) are the institutional 
smartcards that tend to include stored-value  of various kinds that are 
supported at various kinds of merchant &/or transient terminals (i.e. 
subway turnstyles). the transient tend to be proximity/contactless 
(aka  iso14443) rather than contact (aka iso7816).

these infrastructures use secret keys  especially derived secret keys 
... that are designed to protect the infrastructure from various kinds of 
attacks by others (including the people that posses the card) ... typically 
fraudulent value substitution on the card.
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Encryption of data in smart cards

[Anne & Lynn Wheeler]

At 10:39 AM 3/11/2003 +0530, N. Raghavendra wrote:
Can anyone point me to sources about encryption of data in smart
cards. What I am looking for is protocols for encrypting sensitive
data (e.g., medical information about the card-holder), so that
even if the card falls into malicious hands, it won't be easy to
read that data.
a lot of cards use derived (symmetric) keys ... similar to the derived key 
per transaction X9 standards. they are used to protect data from outside 
examination and in multi-function cards to provide protection domains 
between the different applications on a card.

typically there is a system wide key that you would find in a secure 
terminal (like transit systems) that read data, decrypt it, update it, 
re-encrypt it and write it back to the card. this handles situations 
involving attacks with fraudulent readers that load fraudulent value on the 
card.  given the possibility of a brute force attack on the infrastructure 
(aka getting the data out of one card, and finding the master system key) 
... many systems go to some form of derived keys. They typically amount to 
one-way function that combines the system-wide key with something like an 
account number from the card that results in the derived key. A brute force 
attack on the card data  will only result in obtaining the 
card-specific, derived key  and not the system-wide master key. All 
secured readers, knowing the system wide key and some card identification 
can always calculate the  derived key for a card.

misc. derived key stuff ...
http://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aepay10.htm#33 pk-init draft (not yet a RFC)
http://www.garlic.com/~lynn/2002e.html#18 Opinion  on smartcard security 
requested
http://www.garlic.com/~lynn/2002f.html#22 Biometric Encryption: the 
solution for network intruders?
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Question regarding group management of documents

[Anne & Lynn Wheeler]

I was at a presentation last week of a company that is doing something like 
this  including cross-domain authentication. it looked very much like 
kerberos architecture but using packets with SAML formated data (as tickets).

they listed several financial institutions as well as some gov. operations
http://www.sigaba.com/

random saml related references 
http://www.garlic.com/~lynn/aadsm11.htm#19 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D 
Secure
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#6 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#58 Time to ID Identity-Theft Solutions
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aepay10.htm#57 SAML Just The Start For Web 
Services Security
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow 
to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay11.htm#1 Sun releases Liberty-enabled software


At 09:38 AM 1/16/2003 +0100, Birger Toedtmann wrote:

Hi,

can anyone pinpoint me to some papers on this - the Net did not show
up anything useful (and I hope it's not my lacking competence in using
Google).


I'd like to use a server to share documents between users.  The users
are grouped, i.e. a user of group A should not be able to read the
docs of group B (if not a member of it).  There are conceptually two
possible ways to design this:

 * use an "out-band-process" (an operating system watching over
   file permissions, a web service verifying user credentials etc.)

 * use in-band crypto on the document itself, i.e. the "permissions"
   are inherently tied to the bits it consists of

I wanted to use the latter with a critical constraint: ease of deploy-
ment (at least in a sense) which basically means that we don't want
to write a new client but use freely available ones.  So my first
guess was to PGP-encrypt the files on the server using the public
keys of the group-members.  The server obviously should not have the
secret keys of them.  I further assume that (a) a member-no-more takes
his secret key with him and (b) the server may be hacked but the hacker
should not be able to read the documents (but may corrupt/delete them).

So far, so good.  Now a user leaves a group.  As the server is not
able to decrypt files and we don't want someone to decrypt 1000 files
of a group and re-encrypt them again with the members left, it would
be possible to just encrypt the already-crypted file again with the
"new" group of the remaining members (adding sort of a second armor).
Despite this being quite stressing for users if a file has some-20
armors, I did not come up with an idea for adding *new* members to a
group


Well, maybe I'm already on the wrong track for this issue, so I
appreciate any suggestions or hints to sites/papers discussing these
problems.


Regards,

Birger Tödtmann

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

--
Anne & Lynn Wheeler  [EMAIL PROTECTED],  http://www.garlic.com/~lynn/ 


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

Re: Micropayments, redux

[Anne & Lynn Wheeler]

At 12:19 PM 12/16/2002 -0500, R. A. Hettinga wrote:


If they could get plugged into the ACH/ATM network, it might work
there as well, so you could also sell it to banks, if they're buying.


something that is plugged into the ach/atm network

1) those "gift" (stored-value magstripe cards at checkout counters  
operate over the same POS terminal that credit, debit, ach, atm already 
work over. basically large percentage of infrastructure already supports 
... as part of the basic point-of-sale infrastructure ... credit, debit, 
and stored-value.

nacha has already demonstrated (digitally signed) aads debit transactions 
working in the network
http://www.garlic.com/~lynn/index.html#aads

the issue is generalized routing of x9.59 digitally signed transactions ... 
whether they are debit, credit, or stored-value ... and issues like POS 
terminals supporting hardware token (7816 contact or 14443 proximity) 
interfaces capable of digital signatures.

with that then there would also be generalized support for debit & 
stored-value in non-face-to-face, non-POS, and internet type environments 
 aka signed x9.59 transactions whether they are credit, debit or stored 
value. credit was relatively straight-forward translation to the internet 
since it already had relatively similar risk factors accountable for with 
MOTO transactions.  digitally signed transactions would reduce some amount 
of the risk  enabling debit & stored-value to also be used in unsecure, 
non-face-to-face environments like the internet (also translating existing 
debit from shared-secret PIN paradigm to a non-shared-secret public key 
paradigm).

slightly related discussion in sci.crypt ng
http://www.garlic.com/~lynn/2002p.html#52
http://www.garlic.com/~lynn/2002p.html#50

and part of related matters with threads in internet-payments
http://www.garlic.com/~lynn/aadsm12.htm#60
http://www.garlic.com/~lynn/aepay10.htm#65
http://www.garlic.com/~lynn/aepay10.htm#66

--
Anne & Lynn Wheeler  [EMAIL PROTECTED],  http://www.garlic.com/~lynn/ 


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

Re: VeriSign unveils new online identity verification services

[Anne & Lynn Wheeler]

slightly related threads from sci.crypt and a couple other mailing lists.
http://www.garlic.com/2002p.html#26 Cirtificate Authorities 'CAs',
--
Anne & Lynn Wheeler  [EMAIL PROTECTED],  http://www.garlic.com/~lynn/ 


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

Re: Cryptogram: Palladium Only for DRM

[Anne & Lynn Wheeler]

At 06:02 AM 9/17/2002 +, David Wagner wrote:
>I wasn't thinking of pure software solutions.  I was thinking of a
>combination of existing hardware + new software: use the MMU to provide
>separate address spaces, and use a secure VM or OS kernel to limit what
>those processes can do.  As far as I can see, this can provide just as
>much protection against viruses for your bank account as Palladium can.
>
>In general, with software and existing hardware working together, I
>suspect we can already do everything Palladium can do, except for the DRM
>and related applications founded on taking control away from the owner
>of the machine.  Maybe I'm missing something.  Still, it seems to me that
>Palladium would much more compelling if it left out the tamper-resistant
>chip and gave up on the semi-coercive DRM-like applications.


couple refs to multics study
http://www.garlic.com/~lynn/2002m.html#8 Backdoor in AES ?
http://www.garlic.com/~lynn/2002m.html#10 Backdoor in AES ?


--
Anne & Lynn Wheeler  [EMAIL PROTECTED],  http://www.garlic.com/~lynn/ 


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

Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]

[Anne & Lynn Wheeler]

al signature
http://www.garlic.com/~lynn/2002h.html#13 Biometric authentication for 
intranet websites?
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002l.html#26 Do any architectures use 
instruction count instead of timer
http://www.garlic.com/~lynn/2002l.html#28 Two questions on HMACs and hashing

--
Anne & Lynn Wheeler  [EMAIL PROTECTED],  http://www.garlic.com/~lynn/ 


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

Re: Smartcard in CD

[lynn . wheeler]

iso format/standard is not only thickness but also flexibility  even
some proximity (iso 14443) cards have had problem in the past with
flexibiity standards because flex tests would stress the coils in the
plastic and cause the connection to the chip to break.



[EMAIL PROTECTED] on 8/31/2002 4:57 arm wrote:


Contactless smart cards typically have coils in the card and the
magnetic field is generated by the reader.

Capacitive coupling is an alternative but requires more precise
alignment and thus doesn't really provide a proximity/vicinity card
like inductive coupling does.

On-board batteries are hard to fit on an ISO-format smart card but
maybe with the new ultra-thin batteries that's no longer the case.
Batteries are perhaps more suitable for a CD.




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

Re: TCPA not virtualizable during ownership change (Re: Overcoming thepotential downside of TCPA)

[lynn . wheeler]

I arrived at that decision over four years ago ... TCPA possibly didn't
decide on it until two years ago. In the assurance session in the TCPA
track at spring 2001 intel developer's conference I claimed my chip was
much more KISS, more secure, and could reasonably meet the TCPA
requirements at the time w/o additional modifications. One of the TCPA guys
in the audience grossed that I didn't have to contend with the committees
of hundreds helping me with my design.

There are actually significant similarities between my chip and the TPM
chips.

I'm doing key gen at very first, initial power-on/test of wafer off the
line (somewhere in dim past it was drilled into me that everytime something
has to be handled it increases the cost).

Also, because of extreme effort at KISS, the standard PP evaluation stuff
gets much simpler and easier because most (possibly 90 percent) of the
stuff is N/A or doesn't exist

early ref:
http://www.garlic.com/~lynn/aadsm2.htm#staw

or refs at (under subject aads chip strawman):
http://www.garlic.com/~lynn/index.html#aads

brand & other misc. stuff:
http://www.asuretee.com/

random evauation refs:
http://www.garlic.com/~lynn/aadsm12.htm#13 anybody seen (EAL5) semi-formal
specification for FIPS186-2/x9.62 ecdsa?
http://www.garlic.com/~lynn/2002j.html#86 formal fips186-2/x9.62 definition
for eal 5/6 evaluation



[EMAIL PROTECTED] on 8/15/2002 6:44 pm wrote:

I think a number of the apparent conflicts go away if you carefully
track endorsement key pair vs endorsement certificate (signature on
endorsement key by hw manufacturer).  For example where it is said
that the endorsement _certificate_ could be inserted after ownership
has been established (not the endorsement key), so that apparent
conflict goes away.  (I originally thought this particular one was a
conflict also, until I noticed that.)  I see anonymous found the same
thing.

But anyway this extract from the CC PP makes clear the intention and
an ST based on this PP is what a given TPM will be evaluated based on:

http://niap.nist.gov/cc-scheme/PPentries/CCEVS-020016-PP-TPM1_9_4.pdf

p 20:
| The TSF shall restrict the ability to initialize or modify the TSF
| data: Endorsement Key Pair [...] to the TPM manufacturer or designee.

(if only they could have managed to say that in the spec).

Adam
--
http://www.cypherspace.org/adam/




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

Re: Overcoming the potential downside of TCPA

[lynn . wheeler]

hum, i guess i somewhat view the situation somewhat in flux ... maybe
analogous to the period when there was a claim that only auto mechanics
should be allowed to drive automobiles  and only automobiles that
required mechanics to drive them should allowed to be built. The situation
today is that while anybody could build their own automobile from scratch,
few actually do.

as to putting together reliable configurations ... i've had a little
experience ... possible you've heard of some of it.

there was this little client/server startup in the valley that was
interested in implementing  server transactions ... with this emerging
technology that required some amount of vetting and maturing. during the
year that my wife and i worked with them on the implementation and
deployment they moved from menlo park to mountain view and changed their
name from mosaic to netscape  the emerging technology is sometimes
referred to as SSL or HTTPS and the transactions they wanted to do are
sometimes now referred to as electronic commerce. Possibly you have heard
of some of this? Does Netscape, SSL, HTTPS, or electronic commerce ring any
bells?

some past integrity and security suggestions:
http://www.garlic.com/~lynn/2001j.html#5  E-commerce security
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean
Anything

no matter how much I wanted the industry to not allow operation of systems
that didn't meet certain criteria, I wasn't succesful.

thread somewhat analogous to this one:
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn1
http://www.garlic.com/~lynn/aadsm5.htm#asrn4

slightly related mumblings on security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61 Security Proportional to Risc

rant about maybe in a couple thousands years security engineering will
reach the maturity level of civil engineering for bridge building
http://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several
common SSL implementations?

How many people participate in the creation of the bridges and roads that
you drive on ... so that you could examine the safety of the road bed
before it is paved over?


[EMAIL PROTECTED] on 8/14/2002 9:54 pm wrote:

... wide ... open ...  <>  Do you even know what Kerchoff's
Principle IS?!  Look, I've been trying to hold back on actual ranting,
but... but...  you really don't get it, do you?



On the contrary, I have one box with all the protection I want: it's never
connected to the net at all.  I have another box with all the protection
that I consider practical for email and web use.  Both run only and exactly
the software I have put on them, which I obtained from sources trusted to
me and which do not and CAN NOT require any further interaction or
authorization whatsoever to run their software.  I have selected software,
on purpose, which denies someone who is not me even the bare possibility of
restricting my ability to run it at some future time.  I have the source
code.

That is what I mean when I talk about trusted computing.  I trust that my
software does what it says it does, is completely open to inspection and
verification by first, second, and third parties, and cannot be denied to
me at any point after I have come to depend upon it, whether or not I have
a net connection at the moment to interact with its creators.  I trust that
I cannot be singled out remotely to have a sniffer installed on my local
machine through a backdoor.  I trust that code I can inspect at the level
of machine instructions is code that cannot keep secrets from me or forever
conceal malign intent.  I trust that I cannot be forced to depend on any
single commercial software provider, whether it be for the OS or for the
"trusted" compiler which can, of course, come from only one source.  I
trust that coercive "upgrades" done for the sake of incompatibility with
existing code,  do not and cannot happen automatically given my system
configuration.

That is trusted computing sir, and TCPA/Palladium is a huge step *backward*
from it.  Anything that runs *ANY* code that cannot be inspected, or which
keeps data that cannot be inspected, is running code that cannot be
trusted.

TCPA/Palladium does not provide trusted computing.  At least not computing
that I can trust in the way I trust what I've got now. In fact, from my
POV, TCPA/Palladium look like ways to enable the running of software which
I *CANNOT* trust. Imagine my excitement at the prospect.

This is a cryptography mailing list.  Do we even want to count the number
of times commercial software providers have come up with some crap and
claimed it was secure, and been just lying to us?  Do I have to recount all
the proprietary, snake-oil encryption systems that relied for its security
on not being inspected?  Do I have to recount the number of ways that
unstudied security designers have given us their best efforts and had them
shot down by p

Re: Overcoming the potential downside of TCPA

[lynn . wheeler]

Just because some cars have anti-theft devices that can be defeated in
seconds  doesn't make all auto anti-theft devices useless.

so you have currently have an environment that has no protection and
everything is totally wide open.

lets say a hardware chip that currently has no tamper resistance and a
whole infrastructure is put in place based on having security based on a
hardware chip. Hypothetically it eliminates allt the non-physical attacks.
however there are still vulnerabilities involving physical attacks on the
hardware components.

Would that be beneficial? Would it be helpful to eliminate all network and
electronic attacks leaving only physical attacks?

One of the issues is that some amount of the population actually has some
sensitivity for dealing with physical attacks. Part of the current problem
is many people don't have any experience dealing with electronic and
non-physical attacks. I would consider the elimination of all electronic
and network attacks as an interesting prospect.

So what does the world currently do about physical attacks.

Some organizations  if they physical own the device and trying to
protect against outside attacks  might put the device under armed
guards.

If it is DRM, where the chip is, in effect, acting as a proxy agent on
somebody else's behalf then there is issue about protection about physical
attacks by the person in possesion of the device. Tamper-resistance just
ups the cost of a succesful attack. One could hypothesis the value of
something that is always in excess of the protection measures.  i.e.
security proportional to the risk; aka ... regardless of the protection
measures there could always be some hypothetical value making it worth the
cost of mounting an attack.

The hypothetical DRM risk is possibly 90 percent of the infrastructure (not
single, here & there isolated copying  copying being done everywhere).
Would some TCPA possibly both increase the percent of authorized copies and
reduce the unauthorized copies (i.e. a method to reduce unauthorized copies
to zero is by not publishing the works at all). The issue isn't absolutely
ruling out unauthorized copies  the issue is increasing the percent of
authorized copies.

So hypothetically, the environment has reduced all the vulnerabilities and
attacks to attacks just on the physical chip. It is possible that market
forces could  react to such an environment and opportunity.  One
opportunity might be higher priced PCs that have chips evaluated at
EAL7-high with loads of tamper-resistance along with certain works are only
available on machines having the higher evaluated chips.

random mutterings about parameterized risk management:
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
http://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature
initiative stalled
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech9 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re:
KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION
:draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic
signatures
http://www.garlic.com/~lynn/aepay3.htm#x959risk1 Risk Management in AA /
draft X9.59
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment
standard issue
http://www.garlic.com/~lynn/2000.html#46 question about PKI...
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.




[EMAIL PROTECTED] on 8/14/2002 9:19 am wrote:


The problem with this idea is that TCPA is useless.  For all the *useful*
things you are thinking of, you need TCPA plus an approved key.  The only
way you are going to get an approved key is inside a tamper-resistant chunk
of hardware.  If you should manage to extract the key, then yes, you'll be
able to create that CD.  But the idea is that you, the hardware owner, are
not authorized to extract the information contained in your own hardware.
I find the idea of "owning" something without having the legal right to
open it up and look inside legally dubious at best, but I'm no lawyer

The idea is that you shouldn't get anywhere without hardware hacking. The
people doing this have decided hardware hacks are acceptable risks because
they only want to protect cheap data -- movies, songs, commercial software,
whatever.  They are sticking to stuff that's not expensive enough to
justify
hardware hacks.

However, if this infrastructure does in fact become tr

Re: Challenge to David Wagner on TCPA

[lynn . wheeler]

actually it is possible to build chips that generate keys as part of
manufactoring power-on/test (while still in the wafer, and the private key
never, ever exists outside of the chip)  ... and be at effectively the same
trust level as any other part of the chip (i.e. hard instruction ROM).
using such a key pair than can uniquely authenticate a chip 
effectively becomes as much a part of the chip as the ROM or the chip
serial number, etc. The public/private key pair  if appropriately
protected (with evaluated, certified and audited process) then can be
considered somewhat more trusted than a straight serial number aka a
straight serial number can be skimmed and replayed ... where a digital
signature on unique data is harder to replay/spoof.  the hips come with
unique public/private key where the private key is never known.

sometimes this is a difficult consept ... the idea of a public/private key
pair as a form of a "difficult to spoof" chip serial   when all uses of
public/private key, asymmetric cryptograhy might have always been portrayed
as equilanet to x.509 identity certificates (it is possible to show in
large percentage of the systems that public/private key digital signatures
are sufficient for authentication and any possible certificates are both
redundant and superfulous).

misc. ref (aads chip strawman):
http://www.garlic.com/~lynn/index.html#aads
http://www.asuretee.com/



[EMAIL PROTECTED] on 6/13/2002 11:10 am wrote:

This makes a lot of sense, especially for "closed" systems like business
LANs and WANs where there is a reasonable centralized authority who can
validate the security of the SCP keys.  I suggested some time back that
since most large businesses receive and configure their computers in the IT
department before making them available to employees, that would be a time
that they could issue private certs on the embedded SCP keys. The
employees' computers could then be configured to use these private certs
for their business computing.

However the larger vision of trusted computing leverages the global
internet and turns it into what is potentially a giant distributed
computer.  For this to work, for total strangers on the net to have trust
in the integrity of applications on each others' machines, will require
some kind of centralized trust infrastructure.  It may possibly be
multi-rooted but you will probably not be able to get away from this
requirement.

The main problem, it seems to me, is that validating the integrity of the
SCP keys cannot be done remotely.  You really need physical access to the
SCP to be able to know what key is inside it.  And even that is not enough,
if it is possible that the private key may also exist outside, perhaps
because the SCP was initialized by loading an externally generated
public/private key pair.  You not only need physical access, you have to be
there when the SCP is initialized.

In practice it seems that only the SCP manufacturer, or at best the OEM who
(re) initializes the SCP before installing it on the motherboard, will be
in a position to issue certificates.  No other central authorities will
have physical access to the chips on a near-universal scale at the time of
their creation and installation, which is necessary to allow them to issue
meaningful certs.  At least with the PGP "web of trust" people could in
principle validate their keys over the phone, and even then most PGP users
never got anyone to sign their keys.  An effective web of trust seems much
more difficult to achieve with Palladium, except possibly in small groups
that already trust each other anyway.

If we do end up with only a few trusted root keys, most internet-scale
trusted computing software is going to have those roots built in. Those
keys will be extremely valuable, potentially even more so than Verisign's
root keys, because trusted computing is actually a far more powerful
technology than the trivial things done today with PKI.  I hope the
Palladium designers give serious thought to the issue of how those trusted
root keys can be protected appropriately.  It's not going to be enough to
say "it's not our problem".  For trusted computing to reach its potential,
security has to be engineered into the system from the beginning - and that
security must start at the root!

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




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

Re: Feasability of Palladium / TCPA

[lynn . wheeler]

there are two possible answers:

1) it just has to be at least as secure at the risks (doing something might
improve the situation so that some number of vulnerabilities ... but not
all ... are minimized).

2) one of the excuses for not spending the money on secure software ... as
opposed to the current process  is it wouldn't improve anything because
everything else is insecure. so there is a huge chicken and egg situation
 no single operation should do anything about security because the
hundred of other organizations that are involved in producing insecure
components are not doing anything about security
(nobody should do nothing because everybody else is doing nothing).

I've been railing about the buffer-overflow vulnerability every since we
did the vulnerability analysis for ha/cmp in the late 80s  it is just
another on the list of things that need fixing also. some general stuff:
http://www.garlic.com/~lynn/subtopic.html#fraud
http://www.garlic.com/~lynn/subtopic.html#assurance







tim dierks.org on 8/12/2002 10:12 am wrote:


I haven't done an in-depth reading of available information of
Palladium/TCPA specifications, but my understanding is that there is a
private key stored in hardware and a contiguous chain of trust that extends

from the hardware/BIOS through the OS to an application, with each level
validating the superior levels; specifically, the hardware/BIOS validates
the OS as compliant, and then the OS validates an application's identity.
The OS then vouches for the application to the BIOS, giving the application

the ability to make indirect use of the hardware private key in order to
engage in application-level communication with an attestation of the
integrity of all levels (hardware, OS, application).

Here's my question: who thinks this can actually be made secure? Having
spent some time looking at such security issues, developing software, and
watching security alerts fly by for software, I think there's almost no
chance that the attestations made by the OS can be very secure.

Given the nature of PC software platforms, with the size, complexity, and
diversity of vendors, I think it is guaranteed that there will be software
bugs that will allow attackers to run rogue code inside another
application's address space or otherwise cloak themselves in another
application's trust attestation. The attacker can thus get access to
protected secrets or the ability to convince a remote system that they are
an authentic & secure software instance.

Does anyone not believe that there's not going to any buffer-overflow type
bugs in drivers for third-party sound cards that will allow an attacker to
execute code as some other application? And what can be done about? It's
certainly not viable to require dramatically more code review & security in

applications & drivers: I don't think Microsoft & Intel are willing to
sacrifice the economic viability of the platform on the throne of DRM. It's

also not acceptable to customers to require that all code running on the
platform be signed & authorized (unless you're willing to destroy the
industry of software developers who are not large enough or reliable enough

to get such signatures, including the entire open source industry). I don't

believe it's technologically feasible to design a software platform that
can reliably determine the complete chain of control resulting in an API
entry-point being called. (Among other things, you can execute an attack
without having your return address address on the stack.)

Bottom line, I don't think that TCPA or Palladium will be reliable enough
to really constrain those who wish to penetrate it. Given that, I don't
think that there will be as high a value put on the technology by vendors &

rights holders (since their stuff can be stolen by others anyway). If
there's not a high differential value to these architectures, then
presumably the market will not support a high differential price, and the
technologies will not see widespread acceptance.

  - Tim Dierks

PS - I'm looking for a job in or near New York City. See my resume at





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

Crypto Forum Research Group ... fyi

[lynn . wheeler]

To IETF-Announce ;
Subject Crypto Forum Research Group
>From Vern Paxson <[EMAIL PROTECTED]>
Date Fri, 26 Jul 2002 163850 -0400
Sender [EMAIL PROTECTED]


A new IRTF research group, CFRG (Crypto Forum Research Group), has begun,
with the appended charter.  Use [EMAIL PROTECTED] to subscribe to the
mailing list.  See http//www.irtf.org/cfrg/ for further information.


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The Crypto Forum Research Group (CFRG) is a general forum for discussing
and
reviewing uses of cryptographic mechanisms, both for network security in
general and for the IETF in particular.

CFRG serves as a bridge between theory and practice, bringing new
cryptographic techniques to the Internet community and promoting an
understanding of the use and applicability of these mechanisms via
Informational RFCs (in the tradition of, e.g., RFCs 1321 (MD5) and 2104
(HMAC)). Our goal is to provide a forum for discussing and analyzing
general
cryptographic aspects of security protocols, and to offer guidance on the
use
of emerging mechanisms and new uses of existing mechanisms. IETF working
groups developing protocols that include cryptographic elements are welcome
to bring questions concerning the protocols to CFRG for advice.

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

Re: IP: SSL Certificate "Monopoly" Bears Financial Fruit

[lynn . wheeler]

and just to make sure there is a common understanding regarding SSL cert
operation ... the browser code

1) checks that the SSL server cert can be validated by ANY public key that
is in the browser preloaded list (I haven't verified whether they totally
ignore all of the "cert" part of these preloaded public keys ... things
like expiration date ... that these preloaded public keys are in the
preloaded list appears to be sufficient ... details like the preloaded
public keys happened to be wrappered in these certificate containers is
almost extraneous).

2) validates the signature on the SSL server cert with the corresponding
public key

3) checks if the website domain/host name is the same (or in some cases
similar) to the domain/host name specificed in the SSL server cert. I have
noticed that browsers tend to pretty much ignore the contents of these SSL
server certificates ... things like expiration date ... except the public
key, the domain/host name, and the signature (and the signature only has
real meaning within the context of
the infrastructure associated with the public key in the preloaded list
with the lowest trust/integrity level;
this is analogous to security weakest link ... a bank vault with a 4ft
think vault door doesn't do much good
if the vault has no walls).

4) uses the public key in the SSL server cert to validate communication
with the server.

all of this happens automagically from most users' standpoint (probably
less than one percent of the population even knows that there is such a
thing as a preload list).



[EMAIL PROTECTED] on 7/10/2002 at 9:12 pm wrote:

Both Netscape 6 and MSIE 5 contain ~100 built-in, automatically-trusted CA
certs.

 * Certs with 512-bit keys.

 * Certs with 40-year lifetimes.

 * Certs from organisations you've never heard of before ("Honest Joe's
Used
   Cars and Certificates").

 * Certs from CAs with unmaintained/moribund websites ("404.notfound.com").

These certs are what controls access to your machine (ActiveX, Java,
install-
on-demand, etc etc).

  * It takes 600-700 mouse clicks to disable these certs to leave only CAs
you
really trust.

(The above information was taken from "A rant about SSL, oder: die grosse
 Sicherheitsillusion" by Matthias Bruestle, presented at the KNF-Kongress
 2002).

>Why is not someone else issuing certificates?

How many more do you need?

Peter.




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

Re: maximize best case, worst case, or average case? (TCPA)

[lynn . wheeler]

"security modules" are also inside the swipe & pin-entry boxes that you see
at check-out counters.

effectively both smartcards and dongles are forms of hardware tokens 
the issue would be whether a smartcard form factor might be utilized in a
copy protection scheme similar to TCPA paradigm  a single hardware chip
that you register for all you applications  or in the dongle paradigm
 you get a different smartcard for each application (with the downside
of the floppy copy protection scenario where a user with a half dozen
active copy protected applications all wanted "their" smartcard crammed
into the same smartcard reader simultaneously).

many of the current chipcards  i believe are used in the magnetic
stripe "swipe" mode for authenticating specific transactions   most of
the rest are used for password substitute at login type events. Many of the
chipcards following the straight payment card model result in end-user
having large number of different institutional tokens (similar to the
floppy copy protect paradigm).  Following the institutional-specific and/or
application-specific token paradigm starts to become difficult to manage as
the number of tokens increase and the probability that multiple are
required simultaneously increases.

That eventually leads into some sort of person-centric or device-centric
paradigm  not so much an issue of the form factor  (floppy, chipcard,
dongle, etc)  but an issue of whether there are potentially large
numbers of institutional/application specific objects or small numbers of
person/device specific objects.

So a simple issue is the trade-off between the institutional/application
specific objects  which seem to have some amount of acceptance (payment
cards, chip cards, various "dongle" forms, etc) but in many instances can
scale poorly ... especially if  multiple different such objects have to be
available concurrently  vis-a-vis switching to a person/device specific
object paradigm (chipcard, dongles, etc, potentially exactly same
formfactor but different paradigm)



[EMAIL PROTECTED] on 6/30/2002 12:39 pm wrote:


I think dongles (and non-copyable floppies) have been around since the
early
80s at least...maybe the 70s.  Tamper-resistant CPU modules have been
around
since the ATM network, I believe, in the form of PIN processors stored
inside safes)

The fundamental difference between a "dongle" and a full "trusted module"
containing the critical application code is that with a dongle, you can
just patch the application to skip over the checks (although they can be
repeated, and relatively arcane).

If the whole application, or at least the non-cloneable parts of the
application, exist in a sealed module, the rest of the application can't
be patched to just skip over this code.

Another option for this is a client server or oracle model where the really

sensitive pieces (say, a magic algorithm for finding oil from GIS data,
or a good natural language processor) are stored on vendor-controlled
hardware centrally located, with only the UI executing on the end user's
machine.

What I'd really like is a design which accomplishes the "good" parts of
TCPA,
ensuring that when code claims to be executing in a certain form, it really
is,
and providing a way to guarantee this remotely -- without making it easy
to implement restrictions on content copying.  It would be nice to have the
good parts of TCPA, and given the resistance to DRM, if security and TCPA
have their fates bound, they'll probably both die an extended and painful
death.

I suppose the real difference between a crypto-specific module and a
general
purpose module is how much of the UI is within the trusted platform
envelope.
If the module is only used for handling cryptographic keys, as an addition
to
an insecure general purpose CPU, with no user I/O, it seems unlikely to be
useful for DRM.  If the entire machine is inside the envelope, it seems
obviously useful for DRM, and DRM would likely be the dominant application.
If only a limited user IO is included in the envelope, sufficient for
user authentication and keying, and to allow the user to load
initially-trusted code onto the general purpose CPU, but where the user
can fully use whatever general purpose code on the general purpose CPU,
even uncertified code, with the certified module, it's not really useful
for DRM, but still useful for the non-DRM security applications which are
the alleged purpose behind TCPA.

(given that text piracy doesn't seem to be a serious commercial concern,
simply keeping video and audio playback and network communications outside
the TCPA envelope entirely is good enough, in practice...this way, both
authentication and keying can be done in text mode, and document
distribution control, privacy of records, etc. can be accomplished,
provided
there is ALSO the ability to do arbitrary text processing and computing
outside the trusted envelope, .)

If it's the user's own data being protect

Re: maximize best case, worst case, or average case? (TCPA)

[lynn . wheeler]

I remember looking at possibility at adding tamper resisistent hardware
chip to PCs back in 83 or 84 time frame (aka the TCPA idea for PCs is going
on at least 20 years old now).  It was the first time I ran into embedding
chip in a metal case that would create electrical discharge frying the chip
if the container was breached.

Remember when applications came with their own copy-protection floppy
disks?  it was possible to build up a library of such disks 
requiring all sorts of remove, search, insert ... when switching from one
application to another. They eventually disappeared ... but imagine if they
had survived into the multitasking era  when it would have been
necessary to have multiple different copy protection floppy disks crammed
into the same drive at the same time. The chip was suppose to provide an
analog to the CPU serial number used for licensing software on mainframes
 dating at least from the original IBM 370s (store cpuid hardware
instruction).

Some of the higher-end applications still do that with some form of dongle
(originally in the serial port) that comes with the application  it
doesn't quite have the downside of trying to cram multiple floppies into
the same drive concurrently; the serial port dongles allow for them to be
inline cascaded ... and in theory still be able to use the serial port for
other use at the same time.

i believe that there is some statistic some place about the UK and the US
are really great  that in those two countries the copyright piracy is
estimated to only be 50 percent.



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

Re: Welome to the Internet, here's your private key

[lynn . wheeler]

There are very good reasons for having hardware tokens as part of 2/3
factor authentication ... i.e. the hardware token is a "something you have"
 and very good reason for such hardware tokens to become ubiquitous.
Now if there is USB plub&play for things like PC/SC  ... there is much
lower dependency on what the form factor that hardware token needs to take
(modulo some of the EU finread standards issues) that it would be
transparent to software whether it is talking USB to dongle hardware token
or usb reader+card.

As mentioned previously  the issue regarding divulging the private key
is a business issue. Using public/private key in an authentication business
scenario has a real requirement that the private key not be known to
minimize impersonation issue. However, public/private key in encryption
business scenario involving valuable corporate assets could lead to "loss"
of those assets of there is a token/private-key  failure/loss/stollen.
Where private key is being used in business scenario involving protection
of valuable corporate assets  there is real requirement for high level
of redundancy ... and the "impersonation" scenario doesn't apply as it does
in the authentication business scenario; aka while the technology may be
the same ... the different requirements are driven from the business needs
& applications.

it is possible to establish business practices and audit procedures to
significantly increase confidence in the operation of hardware tokens. ...
misc. aads chip strawman discussions
http://www.garlic.com/~lynn/index.html#aads

impresonation refs:
http://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet,
here's your private key
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)

misc. eu finread discussions
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel
Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip
Market

1/2/3 factor authentication
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about
Digital Signatures
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose14 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose15 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital
Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the
wall?
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001g.html#1 distributed authentication
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean
Anything?
http://www.garlic.com/~lynn/2001j.html#49 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security




jaap-henk hoepman <[EMAIL PROTECTED] on 2/8/2002 9:12 am wrote:


I think there _are_ good business reasons for them not wanting the users to
generate the keys all by themselves. Weak keys, and subsequent compromises,
may give the CA really bad press and resulting loss of reputation (and this
business is built on reputation anyway). So: there are good reasons not to
let the CA generate the private key, but also good reasons to not let the
user generate the keys all by himself.

So the question is: are there key generation protocols

RE: Welome to the Internet, here's your private key

[lynn . wheeler]

One could claim that one of the reasons for using RSA digital signatures
with smart cards rather than DSA or EC/DSA is the DSA & EC/DSA requirement
for quality random number generation as part of the signature process.

A lot of the RSA digital signatures have the infrastructure that creates
the message to be signed to also generate and include a large random number
(nonce) in the message. This was acceptable to a large class of smartcards
that didn't have quality random number generation (either for the purposes
of ken-gen and/or signatures). Effective because of the short-comings of
the random number generation ... they had external source doing the key-gen
and injecting the key ... along with no requirement for (on-card) random
number during the signing process (typically a requirement that the
external source include a random nonce in the body of the message).

1) A typical message would have a 20-byte nonce random number, which
computed to a 20-byte SHA1 and then encrypted with RSA resulting in 20-byte
signature (basic message plus 40-byte infrastructure overhead, signature
plus nonce).

2) It is possible to compute a 20-byte SHA1 against the basic message, and
then do a DSA signature resulting in 40-byte signature (basic message plus
40-byte infrastructure overhead).

The difference between #1 and #2 is that a smartcard has eliminated any
dependency in number #1 on the infrastructure providing the message with a
random number.


Cards with quality random numbers ... can

1) do on card key-gen
2) use DSA or EC/DSA
3) remove dependency on external source to include random number in message
to be signed.

DSA & EC/DSA because they have a random number as parting of the signing
process precludes duplicate signatures on the same message ... multiple
messages with the same content & same exact signature is a replay. DSA &
EC/DSA doing multiple signings of the same content will always result in a
different signature value.

I've heard numbers on many of the 8bit smartcards ... power-cycle the card
each time it is asked to generate a random number  do random number
generation 65,000 times and look at results. For some significant
percentage of 8bit cards it isn't unusual to find 30 percent of the random
numbers duplicated.



[EMAIL PROTECTED] on 2/4/2002 2:17 pm wrote:


An 8-bit 1/2 MIP smart card can generate 1024 bit RSA key
pair in about 20 seconds and 512 bit key pair in less
than 5 seconds.

Since this isn't typically done in the checkout lane
this is certainly an acceptable time/security trade-off
by many lights.  A device that can't generate a key pair
probably has other more compelling shortcomings as a
security token.

Cheers, Scott





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

RE: Welome to the Internet, here's your private key

[lynn . wheeler]

ignoring for the moment the question of why certificates would be needed at
all 

then public/private key technology is currently being used for (at least)
two distinct & different business processes

1) authentication
2) encryption

The business process of human person authentication has some requirements
about impersonation ... leading to a business requirement that only the
person being authenticated should have access to the authentication
material (aka only the specific person can originate an authenticated
transaction). A hardware token that generates the key-pair inside the token
and the private key can never leave the token can satisfy unique person
authentication thru one-factor authentication "something you have". The
person is the only one with their specific token and that token is the only
container for their specific private key.

The business process for encryption can be totally different. The assets
being encrypted may be corporate assets, not the individuals. In the case
of using public/private key in conjunction with encryption of corporate
assets, the business requirements totally change. The corporation has a
valid requirement for recoverying valuable corporate assets under any
condition (failure/loss of token, person leaves the company, etc).

In the person authentication case, the impersonation issue typically is
viewed as outweighing the failure/loss of token issue. In the case of
encryption of corporate assets, the failure/loss of the token issue would
typically outweight any issues of guarenteeing absolutely that the key can
only occur in a single place not knonw by anybody.

The requirement for a private key only existing in a single place under
control of a single person isn't an attribute of the public/private key
technology  it is an attribute of a specific business process and
associated business requirements related to that business process. However,
there are other business process applications for public/private key
technology than human person authentication which can have somewhat
different requirements.

aads chip strawman  public/private key hardware token w/o any
certificates
http://www.garlic.com/~lynn/index.html#aads

random refs:
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk
Management and Information Security
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12 A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm10.htm#diskcrypt Looking back ten years:
Another Cypherpunks failure (fwd)
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq




[EMAIL PROTECTED] on 2/4/2002 9:13 am wrote:


One other scheme I've seen, and which, while it doesn't give me
warm fuzzies, seems reasonable, is to issue the
the enduser a smartcard with a keypair on it. The SC generates
the pair onboard, and exports only the public half. The private
half never leaves the SC (there is no function on the card to
export it).

If you trust the above, then the only copy of the private key
is on the SC, despite it having been generated without the
end users participation.

Peter





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

Re: biometrics (addenda)

[lynn . wheeler]

note however, with regard to the 80 hardware tokens, or 3 hardware tokens,
or 1 hardware token scenario  a single or small number of hardware
tokens (with each hardware token having an associated public key registered
multiple places) then can become a personal choice.

The current scenario with shared secret demands that a unique shared secret
be used in each unique security domain.

In the hardware token scenario the same hardware token can be used with
multiple unique security domains w/o exposing the ability to originate
fraudulent transactions.

The biggest exposure is lost/stolen and effectively denial of service.

Since these hardware tokens are many more times harder to compromise than
evesdropping a pin/password, possibly a thousand times harder (which
includes the act of physical theft), then potentially the security profile
allows such a token to be used in a hundred different security domains
(exposure proportional to difficulty of compromise).

This doesn't take into account the human operational factors  like
memory problems with multiple "secret" values ... and if there are multiple
tokens, each with a large number of security domains, remembering which
security domain is associated with which token.






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

Re: biometrics

[lynn . wheeler]

in the most recent PC magazine (2/12/2002) on the stands ... there is an
article "Why Passords Don't Work" (pg. 68

In the article they repeat the recommendation that you never use/register
the same shared-secret in different domains ... for every environment you
are involved with ... you have to choose a different shared-secret. One of
the issues of biometrics as a "shared-secret password" (as opposed to the
interface between you and your chipcard) is that you could very quickly run
out of different, unique body parts.

there are large number of different ways of havesting shared secrets (pin,
password, or biometric) ... the issue isn't so much whether or not pin,
passwords, or biometrics can be harvested  it refers to the business
process distinction between "shared-secret" passwords, pins, or biometrics
registered in various databases ... and "secret" passwords, pins, or
biometrics that aren't registered in various databases.


[EMAIL PROTECTED] on 1/26/2002 10:47 am wrote:

4
Shared "secret"? People don't leave a copy of their PIN on every water
glass they use.

 -- sidney






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

Re: biometrics

[lynn . wheeler]

at least part of the fingerprint as a PIN ... isn't the guessing issue &/or
false positives  it is the forgetting issue (and the non-trivial number
of people that write their PIN on the card).




[EMAIL PROTECTED] on 1/28/2002 4:00 pm wrote:

The essential problem I've always seen with biometrics (and one that
Dorothy Denning acknowledged in her recent op ed piece without seriously
examining) is the question of whether it's as efficient to deploy and
manage biometrics safely as it is to deploy and manage some keyed
alternative like smart cards or other tokens.

Once you start embedding crypto secrets into your biometric reader, you are

no longer managing biometrics. You're now managing BOTH biometrics AND a
bunch of crypto keys. Why not just save yourself the administrative
headache, deploy tokens, and use that crypto key for authentication?

I'm sure there are applications where biometrics make sense (ATMs, door
security, and other closed systems like that) but I just don't see them
working in an open system where your main problem is to associate the
endpoint with a person. If you also need to separately authenticate the
endpoint, and that's what everyone recommends, then the system costs go up
even more.

My favorite biometric implementation is the "fingerprint as PIN" token,
which several vendors make. There's the Sony Puppy, a credit card
calculator sized token with a USB cord and an embedded public key pair.
There are also various PCMCIA readers that (apparently) you can plug in to
your laptop to provide a biometric lock.

My impression, however, is that these readers provide a PIN-like resistance

to attack. Once you've cranked the false rejections down to the point that
it's convenient, the false positives are approaching PIN levels (2^13
guesses on average).

A nice feature of the "fingerprint as PIN" tokens is, of course, that the
print never leaves the card. You still have to worry about images of
fingerprints or rubber fingers, of course. The print is a back-up for
physical possession.


Rick.
[EMAIL PROTECTED]roseville, minnesota
"Authentication" in bookstores http://www.visi.com/crypto/






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

Re: Fingerprints (was: Re: biometrics)

[lynn . wheeler]

I believe NIST published something about FBI needing 40 minutia standard
for registration in their database.

On tv you see these things about lifting partial prints and then sending
them off to FBI to try and find who the partial print matches with, aka the
FBI better have rather detailed recording of whatever part of the print
that happened to be lifted.

That is significantly different than trying to repeat scans in the same
way, on nearly identical surface, from the same angle, of a "full" print
etc. and approx. match at least a minimum number of points. By comparison,
the fbi might need to have higher number of point match based on only a
very specific subarea. That would imply that the needed resolution of valid
points on the minimum acceptable sized subarea equivalent to typical
matching of a full fingerprint.

lets say that FBI wants to do acceptable minutia match on a 15 percent
finger subarea (pure conjecture on my part, i've never even read anything
about minimum resolution needed in partial print search)  ... then
presumably the (fbi's) total finger resolution (recording) might need to be
six times higher than a straight-foward comparison involving always
matching a full-finger to the same full-finger recording using essentially
the same methodology each time.

Even at that, the straight-forward fingerprint match (as opposed to the
partial print search problem)  is frequently subject to greasy & dirty
finger problems.




[EMAIL PROTECTED] at 1/28/2002 1:46 pm wrote:



Last week I had to go to my local INS office to get fingerprinted
(part of the green card process is getting your fingerprints OK'ed by
the FBI (and also presumably stored for future reference)).  The
process is computerised, with a low-res scan of all the fingers taken
once, and then each finger is individually rolled and scanned on a
much higher resolution scanner.

The process took about 20-30 minutes;  each finger had to be wiped
with some cleaning fluid, the glass on top of the scanner also had to
be wiped between scans, and a fingerprinting technician had to roll
each of my fingers with the right amount of pressure to get a clear
image of the fingerprint.  Even with immediate feedback on a large
screen showing the fingerprint and how good the scan was, some fingers
took as many as five tries to get an acceptable fingerprint.

Now, this was a special-built device whose only purpose is to scan
fingerprints, operated under ideal conditions by a trained
technician.  Draw your own conclusions about the effectiveness of
mass-produced fingerprint scanners that would be integrated in other
devices.

/ji

--
 /\  ASCII ribbon  |  John "JI" Ioannidis * Secure Systems Research
Department
 \/campaign|  AT&T Labs - Research * Florham Park, NJ 07932 * USA
 /\against |  "Intellectuals trying to out-intellectual
/  \  HTML email.  |   other intellectuals" (Fritz the Cat)




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







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

Re: biometrics (addenda)

[lynn . wheeler]

so a counter measure for the card stolen scenario ... just to make the
fingerprint compromise of the card slightly harder than the common scenario
of the PIN compromise with a PIN written on the card (this is in addition
to various liveness tests built into sensors).

... lets say you register the the little finger and the finger next to the
little finger  from the hand that you are least likely to use when handling
a card (or water glass).  Either of those two fingers are used
in the chip scenario case, both the PIN/password and biometric are claimed
to have a non-shared-secret paradigm implementation  aka  PIN/password
and/or the biometric are registered in your card  not someplace else.
The issue of the card operating is based on the card comparing the
information.

The assumption is

1) chip-based
2) non-shared-secret paradigm
3) common situation where people write PIN on the card
4) compromise starts with the minimum of stealing the card first.

So the issue for this non-shared-secret, "something you have"  paradigm is
can "something you are" be used in place of "something you know" (and the
associated short-comings) and be more difficult to compromise (not
impossible, just more difficult ... and therefor cost more for the
attacker).

Now, a person that absolutely guarentees that they will use a minimum of
8digit random PIN and never write it anywhere  could elect to have a
card that was PIN operated rather than biometric operated. In the card
case, the transaction works the same  it is just a infrastructure issue
of whether it wants PIN'ed chips or biometric chips. There seems to be a
large body of people where biometric chips is much less subject to
compromise (because of various human memory issues).

random shared secret &/or biometric refs:
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic
signatures
http://www.garlic.com/~lynn/aadsmore.htm#biosigs2 biometrics and electronic
signatures
http://www.garlic.com/~lynn/aadsm2.htm#privacy Identification and Privacy
are not Antinomies
http://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature
initiative stalled
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech12 cardtech/securetech & CA
PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re:
KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION
:draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
http://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX 
password/digital signature
http://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about
Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about
Digital Signatures
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server
security
http://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower
These Terrorists?
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper
Political Cryptography
http://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#3dvulner 3D Secure Vulnerabilities?
http://www.garlic.com/~lynn/aadsm9.htm#carnivore2 Shades of FV's Nathaniel
Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations
on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#biometrics biometrics
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations
regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments
on X9.59 issues.
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
http://www.garlic.com/~lynn/aepay3.htm#x959risk3 Risk Management in AA /
draft X9.59
http://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic 

Re: biometrics

[lynn . wheeler]

again, the issue is cost/benefit trade-off.

The current implementation of pin/magstripe  allows evesdropping &
other techniques to efficiently electronically collect everything need
across a potentially extremely large number of different accounts 
sufficient to perform multiple fraudulent transactions against each one of
them.

In the card/biometric example sited  the water glass example is a total
red herring. the card has to be first stolen in order to perform a
fraudulent transaction. The claim is that it is more difficult & expensive
to fake a biometric lifted off the card than it is to fake a pin written on
the card (aka it is much more likely a fingerprint of interest can be
lifted from the stolen card). This is much more of a exploit than the water
glass red herring  so the counter is how to make it more difficult that
a fingerprint lifted from the card could result in a fraudulent
transaction.




   
   
  Sidney Markowitz 
   
   <[EMAIL PROTECTED]> To:  Cryptography Mailing List  
   
  Sent by:<[EMAIL PROTECTED]> 
   
owner-cryptography@wasabis cc: 
   
ystems.com Subject:  Re: biometrics
   
   
   
   
   
   01/28/2002 10:47 AM 
   
   
   
   
   




On Sun, 2002-01-27 at 14:07, [EMAIL PROTECTED] wrote:
> The issue then is that biometric represents a particularly
> difficult shared-secret that doesn't have to be memorized

Shared "secret"? People don't leave a copy of their PIN on every water
glass they use.

 -- sidney





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







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

Re: biometrics

[lynn . wheeler]

X9.84 biometric standard & some other work means that you could actually
record all ten fingers in the card and any one would be acceptable. I
believe just plain dirty fingers are much more of a problem than a cut.
Simple cut can be "read-around" ... massive cut affecting the whole finger
is problem.  unless you are talking about blood contamination if
band-aid is involved which would have to be removed.

What happens when a person forgets their pin (password) (one of the most
common customer call center calls ... and represents a significant
percentage of total customer call center costs when pin/password support is
involved)? One of the reasons that suprising percentage of cards have PINs
written on them (and postits with passwords are found near PCs).

What happens when person doesn't have any fingers? You can still support
pin-pad in parallel ... assuming that pin-pad is acceptable to people w/o
any fingers.

Next level gets somewhat more expensive ... having pin-pad, finger reader,
and say iris scan (recording all ten fingers and both iris (lots of work
that not only are all iris unique, even identical twins ... but left &
right in same person are unique, iris is also possible in most blind
people), plus finger-length scan.






And what happens when I am unable to press my thumb against the reader
because it is bandaged; or when my thumb ID fails because it was
sliced with a knife.






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

Re: Crypto Winter (Re: Looking back ten years: Another Cypherpunks failure)

[lynn . wheeler]

the straight-forward mapping of credit card payment to the internet used
"MOTO" business process (mail order/telephone order, aka existing
non-face-to-face operation) to handle poorly authenticated transactions.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3


the financial industries standard work on that was basically to provide
authenticated transaction using digital signatures to all electronic
payment transactions  with the requirement given the standards group
"to preserve the integrity of the financial infrastructure" ... aka the
x9.59 work applies to credit transactions, debit transactions, ach
transactions, gift card transactions, etc. and applicable to all
environments (internet, non-internet, point-of-sale, etc)

An x9.59 issue is that it removes the requirement for name associated with
the transaction. This meets an EU requirement that at the point-of-sale, an
electronic transactions should be as anonymous as cash.

The claim then is the x9.59 work is privacy neutral  aka identification
is removed from the transaction. To the extent there is any identification
involved  it is in mapping individuals to accounts. Gift cards don't
have mapping of individuals to accounts ... and x9.59 would neither
increase nor decrease the annonymity of gift cards. Gift cards are
typically procssed with the some point-of-sale terminal as existing
debit/credit cards and at least initially typically flow thru the same
network. That means that the current webserver based use of credit cards
 flows into the same network that debit and gift cards flows into. The
issue isn't the mechanics of enabling debit and gift cards for internet
webserver use  the issue is providing authentication in an "open &
insecure" network (the internet) compared to closed/secure network that the
point-of-sale terminals directly connect into. X9.59 is defined to provide
such authentication in a secure manner across all payment transactions.

With respect to credit &/or debit accounts, again X9.59 neither increases
nor decreases the annonymity of those accounts; to the degree that
particular institutions allow annonymity associated with such accounts ...
x9.59 then is privacy neutral in the protocol.

so the issue here is that the bits and pieces of privacy-enhanced payment
transactions already exists and has for some time. a new one doesn't really
need to be invented; the basic issue is really the technology needed to
transission some of these existing privacy-enhanced payment transactions
from closed network to an open network environment.

misc. refs:
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subtopic.html#privacy




[EMAIL PROTECTED] on 1/27/2002 12:08 pm forwarded:



On Saturday, January 26, 2002, at 09:55  PM, Dr. Evil wrote:

> We know that some kind of privacy-enhanced payment system has been one
> of the long-time c'punk goals, probably for at least ten years.  We
> know that we are probably further away from having that be a reality
> than we were ten years ago.  This is excusable; the obstacles are
> enormous.  You need a lot of people to use it before it's useful, and
> there are all kinds of regulatory problems.  And there are a whole
> list of other problems, too.






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

Re: Looking back ten years: Another Cypherpunks failure (fwd)

[lynn . wheeler]

there is another issue here in the corporate world. The issue is
availability of corporate assets. One particular study that showed it up
had to do with budiness that had no backup of critical disk and that disk
had a failure  50 percent of such occurances resulted in the company
declaring bankruptcy within 30 days.

The whole migration of critical business assets out of the enterprise
glasshouse environment to various corporate desktops has highlighted the
fact that more or more critical corporate assets are represented by that
data (simple example can be customer invoices & billing data).

Enterprises that are doing backup of critical data that is shipped off-site
as part of disaster/recovery scenarios are starting to find that such
backups require encryption (if not the original data stored on disk). The
quandrary then is the possible loss of the capability of decrypting the
data when necessary (aka replicated keying material stored in multiple safe
locations).

random ref:
http://www.securefs.com/ Secure File System

The Secure File System (SFS) is a joint project between the University of
Minnesota and StorageTek which aims to provide an easy to use cryptographic
file system. It allows you to store your files securely on remote sites
using normal networking protocols (FTP, HTTP, NFS, etc.). You can store
your files anywhere without worry of unauthorized access. SFS allows
distributed control of protected information through the use of a group
server which is responsible for all file access controls.

SFS currently uses smartcards, through MUSCLE software, for authentication
and signature purposes. We are currently using Linux with a patched version
of UFO, a user-space program that allows us to treat FTP, HTTP, etc. sites
as local filesystems. This patched version allows us to catch any file
requests and send them to another program to determine if they need to be
de/ encrypted. A diagram of the overall operation is available as a PDF
file or GIF. Note: Entire project source code will be available including
cryptographic routines. Our revised paper which was submitted to the USENIX
Security Symposium is also available in ps and pdf formats.



jei <[EMAIL PROTECTED]> on 1/27/2002 6:27 am wrote:


GET #2 is disk encryption.  Yes, it sounds so simple, but it is a
Great Tabboo, and this time there are no excuses.  None.  You don't
need any network effects.  Regulators in the US have little they can
do about it.  There are about half a dozen great Open Source OSes to
work on.  And yet there is nothing.






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

Re: biometrics

[lynn . wheeler]

lets say you are replacing pin'ed magstripe card with a chip card needing
biometric ... say fingerprint (in place of a PIN) along with chip (in place
of magstripe).

there are two issues 1) effort to compromise the biometric is still
significantly more difficult that a normal 4-digit pin and 2) there seems
to be a large population that writes their 4-digit pin number on their card
(as well as numerous tricks of capturing the PIN).

biometric can work almost anywhere if the increment cost of the biometric
infrastructure is off-set by a corresponding decrease in fraud/compromise.
It doesn't have to be perfect.

Even if similar infrastructures used to capture large number of PINs &
magstripe values were used in a chip/biometric infrastructure ... the use
of the biometric would still be dependent of stealing the card ... compared
to the current pin/magstripe ... where both the pin & magstripe can be
captured with some of the techniques.

The issue then is that biometric represents a particularly difficult
shared-secret that doesn't have to be memorized compared to PIN values
which you find people writing on their cards. The biometric has the
advantage of not being written on the card  so simply stealing the card
is not sufficient. Both the biometric value has to be acquired and the
specific card stolen.

Reversing the viewpoint ... rather than can I make a perfect authentication
system using various biometric implementations? ...  Can the addition of
biometrics reduce the current fraud rate in a cost effective manner (not
does it have to totally eliminate all forms of fraud)?



[EMAIL PROTECTED] on 1/27/2002 10:35 am wrote:


Biometric id can only work when you control the hardware and
the adversary does not, and you can also control what
hardware the adversary can bring to fool your hardware.  This
is feasible in an security door, or security checkpoint





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

Re: Limitations of limitations on RE/tampering (was: Re: biometrics)

[lynn . wheeler]

almost all security is cost/benefit trade-off.

hardware token chips are somewhat analogous to bank vaults  if the bank
vault contains enuf value and somebody is motivated enuf ... they will
attempt to find some way to extract the value. This can be either by
attacking the vault directly ... or by attacking the infrastructure
associated with the vault. I don't believe anybody contends that bank
vaults are absolutely impregnable.

the following are discussion of upgrading a magstrip payment card (debit,
credit, gift, etc) with a chip and requiring (x9.59) digital signed
transactions.

http://www.garlic.com/~lynn/aadsm2.htm#straw
http://www.garlic.com/~lynn/aadsm2.htm#strawm1
http://www.garlic.com/~lynn/aadsm2.htm#strawm2
http://www.garlic.com/~lynn/aadsm2.htm#strawm3
http://www.garlic.com/~lynn/aadsm2.htm#strawm4
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3
http://www.garlic.com/~lynn/aepay3.htm#passwords
http://www.garlic.com/~lynn/aepay3.htm#x959risk1
http://www.garlic.com/~lynn/aepay3.htm#x959risk2
http://www.garlic.com/~lynn/aepay3.htm#x959risk3
http://www.garlic.com/~lynn/aepay3.htm#x959risk4

The issue is that the chip is used to do financial transactions ... which
have some "credit limit" characteristics, various types of fraud pattern
analysis, capable of reporting card lost/stolen within reasonable period of
time, etc.

The position is that even w/o PIN &/or biometric controlled chip  it is
still better than today's world where counterfeiting magstripe operation is
relatively easy. At least the actual chip card has to be stolen ... as
opposed to being able to harvest several hundred thousand credit card
account numbers from some webserver and execute large number of fraudulent
transactions w/o much additional effort.

With a chip having some form of PIN &/or biometric control, then even
stealing the card isn't sufficient, the chip actually has to be
subverted/compromised. The issue then is 1) the cost of stealing the card,
2) cost of performing the compromise operation 3) can the compromise  be
performed before the card has been reported lost/stolen, 4) can a
compromised chip be actually used before the card has been reported
lost/stolen.

Reversing the question, can a chip be added to an existing magstripe card
 and does the increased effort required to compromise such a chip
(compared to compromise/counterfeit magstripe) reduce fraud sufficiently to
justify the cost of the chip (and any associated chip acceptor device
infrastructure).


misc. card fraud discussion

http://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower
These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror14 [FYI] Did Encryption
Empower These Terrorists? (addenda to chargebacks)
http://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
http://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate?
(addenda)
http://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose4 Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose5 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel
Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm10.htm#risks credit card & gift card fraud
(from today's comp.risks)
http://www.garlic.com/~lynn/aadsmore.htm#debitfraud Debit card fraud in
Canada
http://www.garlic.com/~lynn/aepay6.htm#fraud Online Card Fraud Thirty Times
That Offline
http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card
fraud"
http://www.garlic.com/~lynn/aepay6.htm#ccfraud3 "out of control credit card
fraud"
http://www.garlic.com/~lynn/aepay8.htm#ccfraud Almost Half UK E-Shopper's
Fear Card Fraud (CC fraud increased by 50% in 2k)
http://www.garlic.com/~lynn/aepay8.htm#ccfraud2 Statistics for General and
Online Card Fraud
http://www.garlic.com/~lynn/aepay8.htm#x959paper Credit Card Fraud and
E-Commerce: A Case Study
http://www.garlic.com/~lynn/aepay9.htm#risks credit card & gift card fraud
(from today's comp.risks)
http://www.garlic.com/~lynn/aepay9.htm#skim High-tech Thieves Snatch Data
>From ATMs (including PINs)
http://www.garlic.com/~lynn/aepay10.htm#3 High-tech Thieves Snatch Data
>From ATMs (including PINs)
http://www.garlic.com/~lynn/aepay10.htm#6 credit card & gift card fraud
(from today's comp.risks)
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit
cards!
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001h.html#67 Would this type of credit card
help online shopper to feel more secure?
http://www.garlic.com/~lynn/2001h.html#68 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#75 Net banking, is it safe???
http://www.garlic.com

Re: CFP: PKI research workshop

[lynn . wheeler]

to be fair ... most commercial CA's have to verify with the domain name
infrastructure as to the owner of the domain name ... before issuing a SSL
domain name server cert. Note however, one of the justifications for having
SSL domain name server cert is because of concerns with regard to domain
name infrastructure integrity issues and things like domain name
hikjacking. Note however, that if the domain name infrastructure has had a
domain name hijack before the SSL server cert is applied for ... when the
CA goes to the domain name infrastructure to verify the domain name
ownership ... it will verify and a SSL server cert can be issued to the
wrong entity (aka the issuing of a SSL server cert is subject to some of
the same integrity exposures as concerns that gave rise to having SSL
server certs in the first place).

Furthermore, some of the proposals to address domain name infrastructure
integrity issues so that CAs can trust their verification as to domain name
ownership ... also eliminates justifications for needing SSL server certs

random refs:
http://www.garlic.com/~lynn/subtopic.html#sslcerts



[EMAIL PROTECTED] on 1/12/2002 12:31 pm wrote:



To be fair,  most commercial CA's require evidence of "right to use"
a FQDN in an SSL server cert.  But your point is apt.






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

credit card & gift card fraud (from today's comp.risks).

[lynn . wheeler]

other postings and recent info from comp.risks:

http://www.garlic.com/~lynn/aadsm9.htm#carnivore3 Shades of FV's Nathaniel
Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/2002.html#19 Buffer overflow
http://www.garlic.com/~lynn/2002.html#20 Younger recruits versus
experienced veterans  ( was Re: The demise  of compa
http://www.garlic.com/~lynn/2002.html#35 Buffer overflow
http://www.garlic.com/~lynn/2002.html#37 Buffer overflow
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow




Date: Mon, 07 Jan 2002 20:07:25 -0500
From: David Farber <[EMAIL PROTECTED]>
Subject: Credit-card cloners' $1B scam

Homemade machines costing about $50 are being used to read credit-card
mag-stripes, without having to steal the cards.  The information is then
e-mailed abroad, where cloned cards are fabricated.  This has become a
billion-dollar-a-year enterprise.

[PGN-ed from Monty Solomon's e-mail to Dave's IP, subtitled Terrorists,
mobsters in on hacking racket, by William Sherman, *NY Daily News*
  http://www.nydailynews.com/today/News_and_Views/City_Beat/a-137421.asp]

  [The gadget was first demonstrated in maybe 1960s at Caltech as part of a
  demo on how poor the mag-striped credit cards were. In spite of that,
they
  won.  Dave]

--

Date: Sat, 29 Dec 2001 09:59:00 -0600
From: Tim Christman <[EMAIL PROTECTED]>
Subject: Mag-stripes on retail gift cards

Here's a link to an article on MSNBC that I found interesting --
  http://www.msnbc.com/news/598102.asp?0dm=C216T&cp1=1

Many retailers are replacing paper gift certificates with small plastic
cards containing magnetic stripes, similar to credit cards.  Ideally, the
purchase of a gift card would result in a database being updated to reflect
the balance associated with the card's unique account number.

Some retailers are using sequential account numbers and have no provisions
to protect against a thief using a mag-stripe reader/writer to re-program a
stolen card or small denomination card so that it matches the account
number
of a larger valued card purchased by someone else.  Many retailers even
provide a convenient 1-800 number so that the thief, knowing many valid
account numbers, can "shop" for a card of significantly greater value.

The RISK: A form of fraud, difficult to trace, involving a minimal
investment in equipment by the thief.  Also note that the thief only
requires the ability to query the back-end database (through the toll-free
number), not the ability to manipulate the records.  Perhaps more
ominously,
the risk is angry family members who find a zero balance on their gift
cards!

Solutions: One retailer, mentioned in the article, uses optical bar-coding
which can't be re-encoded without defacing the card.  Another follows a
technique used by many credit card companies -- extra check digits are
included in the mag-stripe that are not visible on the face of the card.
It
seems astounding that this isn't being done by all.

--




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

U.S. Cyber Security Weakening

[Lynn . Wheeler]

http://www.wired.com/news/infostructure/0,1377,49570,00.html

Reuters
11:15 a.m. Jan. 8, 2002 PST

U.S. computer systems are increasingly vulnerable to cyber attacks,
partly because companies are not implementing security measures
already available, according to a new report released Tuesday.

"From an operational standpoint, cyber security today is far worse
that what known best practices can provide," said the Computer Science
and Telecommunications Board, part of the National Research Council.

"Even without any new security technologies, much better security
would be possible today if technology producers, operators of critical
systems, and users took appropriate steps," it said in a report
released four months after the events of Sept. 11.

Experts estimate U.S. corporations spent about $12.3 billion to clean
up damage from computer viruses in 2001. Some predict viruses and
worms could cause even more damage in 2002.

The report said a successful cyber attack on the U.S. air traffic
control system in coordination with airline hijackings like those seen
on Sept. 11 could result in a "much more catastrophic disaster
scenario."

To avert such risks, the panel urged organizations to conduct more
random tests of system security measures, implement better
authentication systems and provide more training and monitoring to
make information systems more secure. All these measures were possible
without further research, it said.

Investments in new technologies and better operating procedures could
improve security even further, it noted.

Herbert Lin, senior scientist at the board, said information
technologies were developing at a very rapid rate, but security
measures had not kept pace.

In fact, he said, recommendations for improving security made by the
panel a decade ago were still relevant and timely.

"The fact that the recommendations we made 10 years ago are still
relevant points out that there is a real big problem, structurally and
organizationally, in paying attention to security," Lin said.

"We've been very frustrated in our ability to get people to pay
attention, and we're not the only ones," he added.

Increased security concerns after the Sept. 11 attacks on New York and
Washington could provide fresh impetus for upgrading computer
security, Lin said.

But he warned against merely putting more federal funds into research,
noting that it was essential to implement technologies and best
practices already available.

"The problem isn't research at this point. We could be so much safer
if everyone just did what is possible now," Lin said.

For instance, the report notes that passwords are the most common
method used today to authenticate computer users, despite the fact
that they are known to be insecure.

A hardware token, or smart card, used together with a personal
identification number or biometrics, would provide much better
security for the computer system, the report said.

The report urged vendors of computer systems to provide
well-engineered systems for user authentication based on such hardware
tokens, taking care to make sure they were more secure and convenient
for users.

In addition, it said vendors should develop simple and clear
blueprints for secure operation and ship systems with security
features turned on so that a conscious effort was needed to disable
them.

One big problem was the lack of incentives for companies to respond
adequately to the security challenge, the report said.

It said one possible remedy would be to make software companies,
system vendors and system operators liable for system breaches and to
mandate reporting of security breaches that could threaten critical
social functions.





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

Re: Hackers Targeting Home Computers

[lynn . wheeler]

lots of ISPs provide no-server, dial-up service  they could start with
blocking HTTP & other server-type requests going to such ip-address/modem
subpools (i.e. customers that are getting dynamic ip address on dial-up
lines and have specific service agreements that preclude "server-type"
operation on those dial-up service).

some related discussion in various news groups:
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic
rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic
rules, traffic signs, traffic lights  and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic
rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic
rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic
rules, traffic signs, traffic lights   and traffic enforcement
http://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
http://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
http://www.garlic.com/~lynn/2002.html#20 Younger recruits versus
experienced veterans  ( was Re: The demise  of compa
http://www.garlic.com/~lynn/2002.html#24 Buffer overflow
http://www.garlic.com/~lynn/2002.html#25 ICMP Time Exceeded
http://www.garlic.com/~lynn/2002.html#26 Buffer overflow




[EMAIL PROTECTED] on 1/4/2002 2:08 pm wrote:

It surprises me that providers like Earthlink & GTE (I have one DSL on
each) aren't taking measures to filter out virus traffic from infected
systems.  It seems a simple enough task to me.

It seems to me that the biggest cause of the problems are ignorance and
lack of concern as the article suggests.  So rather than complain and rant,

I've setup a non-technical alert list for my friends and family to keep
them informed and safe.

I try to keep the list fun and easy to read.  Its taken a great deal of
time and explaining, but slowly more and more of them are beginning to see
the bigger picture.

My favorite scenario to lay out for my friends is simple and
effective.  Lets say that a hacker gains control of your computer and uses
it to attack another site/system.  Lets say that site is a Fortune 500
company or a military or government site.  Even if you don't get into
trouble, the FBI could still show up on your door step and take your
computer away for analysis.  No more email or web for you.  Oh, and they'll

probably need to sift through your phone records to see if the hacker
dialed out from your computer.  Kiss your privacy goodbye.






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

Re: CFP: PKI research workshop

[lynn . wheeler]

one of the largest financial networks ...  slightly different kind
http://www.garlic.com/~lynn/2001n.html#22


again financial ... discussion of additional kinds of risks/threats

Sound Practices for the Management and Supervision of Operational Risk
http://www.bis.org/publ/bcbs86.htm

Intro ...

The purpose of this paper, prepared by the Risk Management Group of the
Basel Committee on Banking Supervision (the Committee), is to further
the Committee's dialogue with the industry on the development of Sound
Practices for the Management and Supervision of Operational
Risk. Comments on the issues outlined in this paper would be welcome,
and should be submitted to relevant national supervisory authorities
and central banks and may also be sent to the Secretariat of the Basel
Committee on Banking Supervision at the Bank for International
Settlements, CH-4002 Basel, Switzerland by 31 March 2002. Comments may
be submitted via e-mail: [EMAIL PROTECTED] or by fax: + 41 61 280
9100. Comments on this paper will not be posted on the BIS website.






<[EMAIL PROTECTED]> on 12/31/2001 8:32 pm wrote:


to which I would add:

3. Cryptography, and therefore PKI, is meaningless unless you first
define a threat model.  In all the messages with this Subject, I've
only see one person even mention "threat model".  Think about the
varying threat models, and the type of cryptography one would propose
to address them.  Even the most common instance of encryption,
encrypted web forms for hiding credit card numbers, suffers from
addressing a limited threat model.  There's a hell of a lot of known
plaintext there.







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

Re: PAIIN security glossary & taxonomy

[lynn . wheeler]

PAIIN (& PAIN) were from some "security" standards organization and
http://www.garlic.com/~lynn/secure.htm

is a security taxonomy & glossary

http://ww.garlic.com/~lynn/x9f.htm

is somewhat more of a cryptography oriented glossary & taxonomy since it is
taken from the financial standards X9F committee ... which has a heavy
crypto focus. As an aside, X9.59 was done in the X9A10 working group under
the X9A committee ... which is a business process standards focus (while
X9F has security & cryptography focus)  aka X9.59 is a "secure"
business process protocol as opposed to the more traditional X9F
cryptography protocol.

The source for  X9F taxonomy & glossary
Terms merged from X9F document glossaries: WD15782, X509, X9.8, X9.24,
X9.31, X9.42, X9.45, X9.49, X9.52, X9.62, X9.65, X9.69.
Terms from ABA/ASC X9 TR1-1999 replace terms from X9F TG-16 glossary
(identified by lower case x9 instead of upper-case X9). Original source
documents include: X3.92, X3.106, x9.1, x9.5, x9.6, x9.8, x9.9, x9.17,
x9.19, x9.23, x9.24, x9.26, x9.28, x9.30, x9.31, x9.41, x9.42, x9.44,
x9.45, x9.49, x9.52, x9.55, x9.57, x9.62, x9.69 x9.74, x9.76, x9.78, x9.80,
x9.82, and TG-17. (990710)

While the source for "security" taxonomy & glossary:
Terms merged from: AFSEC, AJP, CC1, CC2, FCv1, FIPS140, IATF, IEEE610,
ITSEC, Intel, JTC1/SC27/N734, KeyAll, MSC, NCSC/TG004, NIAP, RFC1983,
RFC2504, RFC2828, TCSEC, TDI, TNI, and misc. Updated 20010729 with glossary
from IATF V3.




[EMAIL PROTECTED] on 1/3/2002 9:26 am wrote:

The PAIIN model (privacy, authentication, identification, integrity,
non-repudiation) is inadequate to represent the uses of cryptography.
Besides the distinction between privacy and confidentiality, I'd like
to point out some additional uses of cryptography which either don't
fit at all or are poorly represented in this model:

Anonymity - the ability to communicate without messages being
attributed to the sender (e.g. remailers).

Confidential verification -- the ability to verify information
without disclosing it (e.g. zero knowledge proofs).

Fragmentation -- dividing control over information among several
parties.

Invisibility -- the ability to communicate or store information
without being detected. This includes stegonography, low probability
of observation communication techniques such as low power spread
spectrum, and measures against traffic analysis such as link
encryption.

Proof of trespass -- The ability to demonstrate that anyone having
access to data knew they were doing so without authorization, (e.g.
for trade secret and criminal evidence law).

Remote randomization -- the ability for separated parties to
create fair and trusted random quantities.

Resource taxing -- techniques to prove a minimum expenditure of
computing resources  e.g. hash-cash.

Time delay -- making information available but not immediately.

Transmission assurance -- anti-jam and anti censorship technology.

Use control -- the whole digital rights management scene.


I'm not suggesting this is a complete list or the best breakdown, but
I hope is shows that the cryptographic imagination goes beyond PAIIN.

Arnold Reinhold









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

Re: CFP: PKI research workshop

[lynn . wheeler]

aka ... lots of people seem to equate privacy with personal privacy (as
well as legislative specification) ... while confidentiality has more of a
non-personal connotation

there seems to be 3-4 postings from yesterday that are still lost in the
ether ... they are recorded at

http://www.garlic.com/~lynn/aadsm9.htm
&
http://www.garlic.com/~lynn/aadsm10.htm

from
http://www.garlc.com/~lynn/secure.htm

confidentiality
(1) The assurance that information is not disclosed to inappropriate
entities or processes. (2) The property that information is not made
available or disclosed to unauthorized entities. (3) The prevention of the
unauthorized disclosure of information. (4) The concept of holding
sensitive data in confidence, limited to an appropriate set of individuals
or organizations. [AJP] Assurance that information is not disclosed to
inappropriate entities or processes. [FCv1] The concept of holding
sensitive data in confidence, limited to an appropriate set of individuals
or organizations. [NCSC/TG004] The prevention of the unauthorized
disclosure of information. [ITSEC][NIAP] The principle that keeps
information from being disclosed to anyone not authorized to access it.
Synonymous with secrecy. [AFSEC] The property that information is not made
available or disclosed to unauthorized entities. [JTC1/SC27/N734] The
property that information is not made available or disclosed to
unauthorized individuals, entities, or processes. [TNI] The property that
sensitive information is not disclosed to unauthorized individuals,
entities or processes. [FIPS140] (see also assurance, data confidentiality,
data confidentiality service, privacy, privacy programs, security)

privacy
(1) The ability of an individual or organization to control the collection,
storage, sharing, and dissemination of personal and organizational
information. (2) The right to insist on adequate security of, and to define
authorized users of, information or systems. Note: The concept of privacy
cannot be very precise, and its use should be avoided in specifications
except as a means to require security, because privacy relates to 'rights'
that depend on legislation. [AJP] (1) the ability of an individual or
organization to control the collection, storage, sharing, and dissemination
of personal and organizational information. (2) The right to insist on
adequate security of, and to define authorized users of, information or
systems. Note: The concept of privacy cannot be very precise and its use
should be avoided in specifications except as a means to require security,
because privacy relates to 'rights' that depend on legislation. [TNI] (I)
The right of an entity (normally a person), acting in its own behalf, to
determine the degree to which it will interact with its environment,
including the degree to which the entity is willing to share information
about itself with others. (O) 'The right of individuals to control or
influence what information related to them may be collected and stored and
by whom and to whom that information may be disclosed.' (D) ISDs SHOULD NOT
use this term as a synonym for 'data confidentiality' or 'data
confidentiality service', which are different concepts. Privacy is a reason
for security rather than a kind of security. For example, a system that
stores personal data needs to protect the data to prevent harm,
embarrassment, inconvenience, or unfairness to any person about whom data
is maintained, and to protect the person's privacy. For that reason, the
system may need to provide data confidentiality service. [RFC2828] (see
also confidentiality, private communication technology, private key,
security, quality of protection) (includes Privacy Enhanced Mail, data
privacy, pretty good privacy, privacy programs, privacy, authentication,
identification, integrity, non-repudiation, privacy, authentication,
identification, non-repudiation, virtual private network)




[EMAIL PROTECTED] on 1/2/2002 9:18 am wrote:

well PAIN is out of some standards organization (as is 3-factor
authentication)  i agree that privacy and confidentiality is sometimes
thot of as different  but others argue that it reduces to the
effectively the same requirements ... even tho different people have
different connotations with the two terms.

i had fumble fingered 3-4 URLs yesterday  and the posting to correct
them seems to have gotten suspended for some time in the ether  note
however the url for the security taxonomy and glossary had been typed
correctly in a posting made earlier in the day ... i.e.
http://www.garlic.com/~lynn/secure.htm










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

Re: CFP: PKI research workshop

[lynn . wheeler]

well PAIN is out of some standards organization (as is 3-factor
authentication)  i agree that privacy and confidentiality is sometimes
thot of as different  but others argue that it reduces to the
effectively the same requirements ... even tho different people have
different connotations with the two terms.

i had fumble fingered 3-4 URLs yesterday  and the posting to correct
them seems to have gotten suspended for some time in the ether  note
however the url for the security taxonomy and glossary had been typed
correctly in a posting made earlier in the day ... i.e.
http://www.garlic.com/~lynn/secure.htm



[EMAIL PROTECTED] on 1/2/2002 7:37 am wrote:


Lynn,

I think you should specify "confidentiality" as another issue to be
addressed.  Perhaps you include confidentiality in your "privacy" or
"security" subsections, but I've found that many people think (and
mean) different things when they use these two terms.  For example, is
privacy necessarily privacy of communicated data from eavesdroppers,
or is it the privacy of personal information (perhaps the privacy of
the authentication information) so an eavesdropper does not know who
is communicating?

Unfortunately your garlic.com URL (security.htm) does not work and
returns an HTTP 404 error.

-derek







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

Re: CFP: PKI research workshop

[lynn . wheeler]

sometimes the "principles" of security are referred to as PAIN or sometims
PAIIN

see
http://www.garlic.com/~lynn/security.htm

and click on PAIN & PAIIN in the acronym section of the glossary.

Doing a threat model ... would include not only end-to-end issues  but
what aspects of PAIIN are being addressed.
privacy, authentication, identification, integrity, non-repudiation (PAIIN)
(see also authentication, identification, integrity, non-repudiation,
privacy, security)

an aspect of security can be integrity and and aspect of integrity can be
dependability  leading to things like:
http://www.hdcc.cs.cmu.edu/may01/index.html

which is then related back to my posting on sunday (with regard to
integrity)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki10 CFP: PKI research workshop





[EMAIL PROTECTED] on 12/31/2001 8:32 pm wrote:


to which I would add:

3. Cryptography, and therefore PKI, is meaningless unless you first
define a threat model.  In all the messages with this Subject, I've
only see one person even mention "threat model".  Think about the
varying threat models, and the type of cryptography one would propose
to address them.  Even the most common instance of encryption,
encrypted web forms for hiding credit card numbers, suffers from
addressing a limited threat model.  There's a hell of a lot of known
plaintext there.






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

Re: CFP: PKI research workshop

[lynn . wheeler]

somewhat as an aside ... the requirement(s) given the X9A10 financial
standards working group for the development of the X9.59 standard was

* to preserve the integrity of the financial infrastructure for all retial
electronic payments without the use of encryption

"ALL" didn't just mean internet or just mean credit  it met "ALL" ...
all environments ... all types of transactions, etc.

"Without the use of encryption" didn't mean that  information hiding wasn't
precluded (say for privacy reasons) but weren't required to preserve the
integrity of the financial infrastructure (aka that complete clear-text
could be made available and it wasn't possible to do a fraudulent
transaction based on everybody in the world potentially having the
cleartext of that payment transaction).

Implied in the requirement was that it had to also be extremely lightweight
in order to be applicable to some of the existing electronic payments
environments. Again "ALL" met "ALL" ... including a large number of
existing electronic environments. Frequently "from scratch" protocol
definitions are faster to do if you don't have to take into account any
existing infrastructure (and/or only addressing an extremely small subset
of the total end-to-end problem)..

To meet the requirements we eventually settled on a very lightweight,
end-to-end authentication definition (strong authentication of every
transaction had to flow completely through from the consumer all the way
through to the consumer's financial infrastructure).

x9.59 references:
http://www.garlic.com/~lynn/index.html#x959




[EMAIL PROTECTED] on 12/31/2001 8:32 pm wrote:


to which I would add:

3. Cryptography, and therefore PKI, is meaningless unless you first
define a threat model.  In all the messages with this Subject, I've
only see one person even mention "threat model".  Think about the
varying threat models, and the type of cryptography one would propose
to address them.  Even the most common instance of encryption,
encrypted web forms for hiding credit card numbers, suffers from
addressing a limited threat model.  There's a hell of a lot of known
plaintext there.






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

Re: CFP: PKI research workshop

[lynn . wheeler]

somewhat as an aside  the "gift" cards (and other flavors) that you see
at large percentage of retail check-out counters in the US are effectively
digital cash ... although the current incarnation results in a different
card at every retailer. however, they are online, magstripe-based digital
cash  utilizing the same ubquituous point-of-sale infrastructure as
debit & credit (it is just that the transaction routing goes to different
online transaction processing than credit & debit). The issue of whether or
not it would be possible to use any card at any merchant is more of a
business rule issue than a technology issue.

note from a higher assurance standpoint ... the x9.59 work is applicable to
all electronic transactions  whether they are credit, debit, e-check,
OR (online)  digital cash ... AND x9.59 transactions could flow over both
existing ubiquituous point-of-sale network and/or a ubiquituous internet
network (or any other kind of network).

random refs:
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/index.html#aads



[EMAIL PROTECTED] on 12/28/2001 4:50 pm wrote:

A "local" financial branch implementation and a digital cash implementation
might have a number of similar useability attributes  aka from the
standpoint of how local funds do you have immediately available  aka
funds are transferred into you local PDA as digital cash for immediate use
 or funds are transferred into the local financial institution for
immediate use.






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

Re: CFP: PKI research workshop

[lynn . wheeler]

another aspect that overlaps PKIs and quality is the difference between
"application" code and "service" code  turning an application into a
service can be hard  possibly writing 4-10 times as much code as in the
base application infrastructure  and very high-quality code 
dealing with potentially very complex failure modes. Related thread
("buffer overflow") has been running in the sci.crypt newsgroups. 
partial reference:
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#90 Buffer overflow

also an older thread regarding "assurance" in application and digital
signature authentication
http://www.garlic.com/~lynn/aadsm5.htm#asrn1 Assurance, e-commerce, and
some x9.59
http://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and
some x9.59
http://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and
some x9.59
http://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, x9.59, etc



[EMAIL PROTECTED] at 12?29/2001 3:22 pm wrote:

Now, an interesting thing might be regarding rapid uptake of general
security. One could contend that majority of the market believes that good,
strong security should be an attribute of the basic infrastructure ...
somewhat like the issue of automobile quality in the '70s, not going to pay
any more for it ... but would migrate to a manufactor that had
significantly better quality. You then have the 1) vendors that  don't see
quality as worth while since they won't be able to charge more 2) new
vendors that would like to sell "quality" as a stand-alone attribute ...
not actually having to manufactor automobiles  but somehow convince
customers that they can sell quality independent of any product, and 3)
vendors that feel that they can eventually gain market share by providing
better quality.

Substitute "security" and/or "PKI" in place of "quality".

Part of the issue is that security (and strong authentication) should be an
attribute of the basic infrastructure ... not something that exists by
itself in a vacuum.







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

Re: CFP: PKI research workshop

[Lynn . Wheeler]

everyday life has a lot of cryptography ... for instance ... there is quite
a bit of cryptography involved in every debit transaction (every time you
get money from ATM machine or use point-of-sale terminal).

a lot of PKI revolves around the business process of strong authentication
 where some aspects of cryptography happens to be used. A subset of
this saw extremely rapid uptake with regard to SSL and online shopping
(again quite a bit of cryptography in use, one might make a case that
cryptography should be like electronic dsitributors, everybody may have one
... but very few could actually build one from scratch or even know thay
actually have one). One might be tempted to make the observation that
uptake rate is much faster if it is filling a new need as opposed to trying
to change existing operation.

However, PKI industry seems to have tried to make public key cryptography
and certificates an "end in themselves". First off, certificates are a
solution to strong authentication in an offline environment (aka early '80s
offline email paradigm) which doesn't have a very good match to most of the
business processes that are in use today.

A PIN debit transaction involves the relying-party (the consumer's bank
both authenticating and authorizing the transaction  authentication
based on something you have and something you know ... and authorization on
a combination of authentication, available funds, any previous transactions
today, the aggregate value of any current day transactions, etc). Digital
signature can improve the integrity of the existing PIN-debit based
operation and also expand the use to open/insecure network (i.e. the
existing PIN-debit is predicated on closed, secure network). This is what
NACHA (national cllearing house association ... aka typically regional and
national financial industry organizations that provide infrastructure for
bank-to-bank wholesale financial transfers) did in the debit demonstration
 basically upgrading PIN-based cyrptography for authentication to
digital-signature cryptography for authentication (where a shared secret
paradigm ... aka PIN-base was replaced with a non-shared secret paradigm).
http://www.garlic.com/~lynn/index.html#aads

There was no certificate necessary ... and, in fact, certificates aren't
really about cryptography, there are more about a specific kind of offline
business process (which is having difficulty finding a niche in an
increasingly online world).

Furthermore, not only is the offline-paradigm certificate model having a
difficulty finding a niche in an online world ... the idea of a purely
authentication business process is possibly having trouble finding its
niche
... referencing prior posting that most business tend to perform
authentication ... a cost overhead ... as part of some useful, productive
business process (not purely an end in itself)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki7

One might envision a Monty Python Department of Authentication. Citizens
are asked to visit their local Department of Authentication every day,
state their name, and provide certificate/credential for proof of their
claimed identity. The Department of Authentication doesn't actually record
that they've prooved any identity and citizens aren't actually mandated to
show up. However, if the citizens do show up everyday to their local
Department of Authentication, it makes the DoA employees feel that they are
providing a useful service in the scheme of the universe (as well as
certificates/credentials that are voluntarily verified everyday are better
than ones that aren't ... something like pet rocks).

Now, an interesting thing might be regarding rapid uptake of general
security. One could contend that majority of the market believes that good,
strong security should be an attribute of the basic infrastructure ...
somewhat like the issue of automobile quality in the '70s, not going to pay
any more for it ... but would migrate to a manufactor that had
significantly better quality. You then have the 1) vendors that  don't see
quality as worth while since they won't be able to charge more 2) new
vendors that would like to sell "quality" as a stand-alone attribute ...
not actually having to manufactor automobiles  but somehow convince
customers that they can sell quality independent of any product, and 3)
vendors that feel that they can eventually gain market share by providing
better quality.

Substitute "security" and/or "PKI" in place of "quality".

Part of the issue is that security (and strong authentication) should be an
attribute of the basic infrastructure ... not something that exists by
itself in a vacuum.



[EMAIL PROTECTED] on 12/28/2001 6:54 wrote:

Several of the comments about the slow uptake of PKI touch on what
seem to be two basic factors that are responsible for this phenomenon:

1.  Cryptography does not fit human life styles easily.  As an example,
truly secure systems would stop secretaries from forging their b

Re: CFP: PKI research workshop

[Lynn . Wheeler]

both atm debit network and domain name infrastructure care capable of local
caching  so that timelyness is within seconds to minutes (or a few hrs
as parameter within the needs of the infrastructure). the offline world for
certificates is the analogy of the letters of credit from the days of the
sailing ships. near real time with managed caching (with relying parties
forced to deal with stale credentials manufactored months or years in the
past).

part of the issue in clearing is who has the "liability" at any particular
instance; in the case of debit network caching there are very specific
procedures and processes. Are you suggesting that the certification
industry will assume liability in the case of offline clearing associated
with mars colonilization?

the process tends to be authentication, authorization, and finally
settlement and clearing. sometimes authorization, settlement and clearing
can be batched. if you are really talking about the bank account balance
resides on the earth and the access is from mars  offline
authentication (clearing really needs to know whether the money actually
exists or not  regardless of whether or not you are dealing with the
owner of the account) doesn't get you clearing  and real clearing needs
to know that the money really exists (not just that a person is
authenticated)  ... and if the account balance is on earth and it takes 30
minutes elapsed time to establish it ... then that it what it takes.

More realistic is account balance caching at some near real-time location
on mars ... say within the parameters of the ATM withdrawal limit.

At one point in the PKI evolution there was the proposal that there could
be certificates analogous to the '70s "signing limit" checks .,... an
attempt to create certificates that not only provided authentication
information but also some hypothetical useful approximation to
authorization information (aka not quite reqressing totally to the pre-70s
credit card model). The issue in the "signing limit" checks was when they
found people writing 200 $5000 (limit) checks to get a million. What has
been seen since that time is near real-time purchasing department operation
(including business purchase cards that leverage the credit card system) to
provide real-time aggregation ... as opposed to sinlge event operation. In
the ATM machine withdrawal case, there are typically both single widthrawal
limits as well as daily aggregate withdrawal limits (aka the PKI proposal
for credit cards turned out to be a business process regression to pre-70s
and the PKI proposal for business checks turned out to be a business
process reqression to pre'80s).

Typically what you might have in a ATM withdrawal case  with foreign
ATM machine (not your local bank)  is that the owner of the ATM machine
is given a guarentee of funds from your financial institution prior to the
ATM machine releases paper money. Your bank then effectively debits your
account for the equivalent amount of funds. Then typically sometime that
evening, there is a settlement operation where there is funds transfer from
your bank to the financial institution that owns the ATM.

An offline, stale certificate  only (slightly) addresses the issue of
authentication  say an identification certificate ... which might not
even provide a binding between you and any particular bank or bank account.
Some sort of binding between you, your bank, and your bank account is
needed  just for the authentication phase of what you are talking
about. There is still the authorization phase needed so that the owner of
the ATM machine believes that it can receive something (in return for
spitting out paper bills).  That effectively has to find that there are
actually sufficient funds in your account.

So a more realistic scenario would be that there is possibly dual account,
one local and one on earth ... with funds floating back and forth as needed
in evening settlements. If you are on Mars there is some local financial
branch with local record of funds that you have immediately available and
which can authorize that amount of money.

A "local" financial branch implementation and a digital cash implementation
might have a number of similar useability attributes  aka from the
standpoint of how local funds do you have immediately available  aka
funds are transferred into you local PDA as digital cash for immediate use
 or funds are transferred into the local financial institution for
immediate use.





ray dillinger <[EMAIL PROTECTED]> on 12/28/2001 2:29 pm wrote:


The only case in which the PKI solution is not redundant is in
offline clearing.  But getting your point-of-transaction online
is easier than paying attention to PKI.

I happen to like offline clearing -- it opens up the possibility of
new transaction types and doing transactions in places you couldn't
before.  But the practical issue is, everybody who's interested in
electronic transactions of any ki

Re: CFP: PKI research workshop

[lynn . wheeler]

I would tend to make the statement even stronger.

large, complex legacy systems tend to have slow technology uptake. most of
the certification authorities can be deployed in simple demos w/o impacting
the legacy systems and business process (possibly as a front-end process
that is pealed off before turning things over to the legacy business
process).

if you have legacy business process designed to support millions or
hundreds of millions of customers ... then any change to that system tends
to be significantly more expensive than a stand-alone certification
authority demo for a couple hundred.  The problem has been the cross over
from toy-demo to real production. In general, the legacy infrastructures
and business processes have been put into place for perfectly valid reasons
 even if somewhat slow to change.

I'm acquanted with one example where a single screen update (as part of a
new function rollout) to a customer call-center supporting tens of million
customer environment cost more than a dozen or so certification authority
demo systems.  The issue was that call center was highly optimized and had
significant investment to scale into handling tens of millions of customers
very, very efficiently. To optimize a single screen & get it integrated
into a real live production environment required some amount of investment.
Such things as customer call-centers (not to mention scallable customer
call centers, scallable administrative and management infrastructure, etc)
for a customer service oriented operation  could be totally ignored
when testing purely demo operations.

However, even with the cost of modifying a legacy operation  where
authentication is integrated into the standard every day business processes
 is significantly cheaper than trying to treat authentication as an
independent service (and build a separate scallable infrastructure that
real customer service orientation involves).

As an aside point ... I've found very few business operations that go
around trying to perform authentication operations purely for the sake and
enjoyment of performing authentication operations. For the most part,
businesses will perform authentication operations (typically viewed as
overhead or cost issue) as part of some real, productive business service
(a revenue issue). I find it difficult to come up with a whole lot of
scenarios where cost overhead (authentication) operations are performed for
no business (revenue) purpose. As mentioned in prior posting
http://www.garlic.com/~lynn/aadsm9.htm#cfppki6

given that authentication is being performed as part of some business
process or function ...  then it is normally trivial to show it is easier
to have authentication (even digital signature authentication) integrated
into such business processes  and correspondingly easy to show that
certificate-based operations are redundant, superfulous and extraneous
(modulo the issue of toy demos are cheaper than modifying production
business operations).





[EMAIL PROTECTED] on 12/28/2001 3:41 am wrote:


Naah, it's the monorail/videophone/SST of security.  Looks great at the
World
Fair, but a bit difficult to turn into a reality outside the fairgrounds.

Peter (who would like to say that observation was original, but it was
actually
   stolen from Scott Guthery).






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

Re: CFP: PKI research workshop

[lynn . wheeler]

it isn't that you move it to a central authority  you move it to an
authority that typically is already established in association with
authorization ... aka in normal business operation, a business relationship
is established that typically consists of creating an account record that
has various privileges associated with that account/entity. For
authentication purposes a public key can be bound to that account and/or
set of privileges. This goes on in the world today  and would continue
to regardless of whether x.509 identity certificates were issued or not.
given that businesses have to play the registration function for
authorization & privileges ... aka normal procedure doesn't allow somebody
to walk into a random bank and withdraw funds from a random account ...
regardless of who they are ... aka indentity doesn't magically enable a
person to withdraw funds from an arbritrary account ... ability to withdraw
funds typically is a privilege associated with whether or not some entity
is authorized to perform that function for a specific account. As such, the
financial institution has to register lots of information for the account
... also registering a public key is consistent with the existing business
processes, liability, administrative and management infrastructure.

In effect, large numbers of business processes already exist for
registration, administration, and management of authentication information
 and having a certificate in the loop doesn't eliminate those business
processes (whether or not I had a certificate  there still would have
to be something registered that some attribute of "me" has authorization to
do certain things). Doing business flow and informatioin management
optimization just demonstrates that given existing business infrastructures
for registration, administration and management which also includes
certificates it is usually trivially possible to demonstrate that the
actual certificates are redundant, superfulous and extraneous ... aka
directly registering the public key and providing direct binding between
the authentication process and the authorization process  eliminating a
possibly huge number of extraneous and unnecessary business entities and
business processes associated with certificate-based operation.

There doesn't have to be any single central authority in a certificateless
model. There can be all sorts of authorities for all sorts of infomation
 which could be also hypothesized for a certificate-based certification
and authentication model. However, the certificateless exercise typically
trivially demonstrates that any certificate-based solution duplicates
existing business processes which aren't going to be eliminated. Therefor,
it is then possible to demonstrate business optimization where the
duplicate (certificate) business processes can be eliminated as extraneous,
redundant, and superfulous.



<[EMAIL PROTECTED]> on 12/27/2001 7:16 am wrote:


As for the "certificateless" model - all this really does is move the
binding from something you can carry around with you to something that
has to be done by a central authority. It is not clear to me why this is
such a marvellous improvement. Unless you happen to want to own the
central authority, of course, which, unlike certificates and CAs, is far
harder to replicate privately and therefore, presumably, potentially
even more profitable than Verisign's cash cow.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff







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

Re: CFP: PKI research workshop

[lynn . wheeler]

for the most part HTTPS SSL is certificate manufactoring (a term we coined
a couple years ago)  "infrastructure" typically implies the
administrative and management  which would require (at a minimum) CRLs
for a certificate-based PKI.

the interesting thing about the use of SSL domain name server certificates
is that they supposedly are addressing an integrity issue in the domain
name infrastructure  i.e. SSL checks that the domain name listed in the
SSL domain name server certificate is the same as the domain name
clicked/typed in for contacting the server. The issue is that the domain
name could be hijacked and instead of going to the "real" IP-address 
it gets rerouted to a fraudulent IP-address.

however, if you track back the trust infrastructure for the SSL domain name
server certificate  the process is somebody applies for a SSL domain
name server certifificate with a certification authority. The standard
operating procedure for certification authorities is that they typically
have to verify the information that they are certifying (in this case
domain name ownership) with the authoritative agency for the information
(in this case the domain name infrastructure). Now since there could be an
integrity problem in the domain name infrastructure with respect to domain
name hijacking ... there in fact could be a domain name hijacking prior to
the application for a certificate  which results in the issuing of a
valid SSL domain name server certificate to the wrong entity.

One of the suggestions for addressing the domain name infrastructure
integrity issue is for public keys to be registered at the same time as the
domain name  and then further communication with the domain name
infrastructure be with digitally signed messages ... as part of the process
for thwarting domain name hijacking. Note however, since the domain name
infrastructure is the registration authority for the public key as well as
the relying party receiving the signed messages  certificates are
redundant, superfulous, and extraneous  even tho it still could be
considered a (certificate-less) "publick key infrastructure" with
significant administrative and management support.

The other interesting aspect is that the existing domain name
infrastructure is set up for (presumably) trusted, (near) real-time
distribution (and updating) of almost any kind of information; not just the
(nearly) trusted binding of domain name to IP-address. Given that public
keys are also registered with domain names at the same time as domain name
and ip-address  then a trusted domain name infrastructure could be
relied upon to implement a (certificate-less) near real-time "public key
infrastructure" (with full administrative and management functions already
in existance)  aka the domain name infrastructure could optionally
distribute public key in the same response that it distributes ip-address
.. eliminating the requirement for a certificate-based PKI for trusted
public key distribution.

This is somewhat a catch-22  that one of the solutions to addressing a
basic SSL domain name certificate integrity problem (i.e. a CA has a broken
trust chain if there is an integrity issue with the authoritative agency
responsible for the information that a certification authority must
certificate) could also be the solution eliminating any requirement for SSL
domain name certificates.

As an aside, having the public key at the same time as the ip-address for
setting up the base TCP session could also be used to simplify the normal
SSL session setup (since there is no certificate distribution that has to
occur).

random additional discussion:
http://www.garlic.com/~lynn/subtopic.html#sslcerts

there is also the claim that 99.9 percent of client authentication in
the internet world today is radius-based; typically userid/password
(although radius supports multiple authentication processes specifiable at
an individual userid/account level). There has been work done on an
authentication process for radius involving digital signature where a
public key is registered in place of a password. This would also represent
a (certificate-less) public key infrastructure with full administrative and
management support.

random raidus discussion
http://www.garlic.com/~lynn/subtopic.html#radius

for pointer to radius standards & documents:
http://www.garlic.com/~lynn/rfcietff.htm

& click on "Term (term->RFC#)

and then click on "RADIUS" in the "Acronym fastpath" section

remote authentication dial in user service (RADIUS )
see also authentication , network access server , network services
3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138
2059 2058

also of some interest are the AAA rfcs:
Authentication, Authorization and Accounting
see also accounting , authentication , authorization
3127 2989 2977 2906 2905 2904 2903




perry e. metzger <[EMAIL PROTECTED]> on 12/26/2001 3:45 pm wrote:

HTTPS SSL does not

Re: CFP: PKI research workshop

[lynn . wheeler]

I doubt if fast/fstc participants would look at the following example as a
prime example  but there are various "age" authentication services that
are available on the internet today ... basically associated with adult
entertainment ... but would also be applicable to online gambling, various
kinds of online purchases (alchohol), etc.  It doesn't have to identify who
you are ... it just has to be able to answer the question that you are at
least of legal age.

now, it turns out that most of these services use effectively a "loop-hole"
in the current online credit card system to implement their age
authentication operation. There is such a thing in the industry called a
"one dollar auth". Credit card operations typically have financial
transactions authentication and authorized in real time  but the actual
request for funds transfer is typically submitted in batches ... at end of
day or possibly end of shift. A "one dollar auth" is an authorization
request for a one dollar credit card transaction, typically also with name
& AVS (address verification) data. If the name, account number, and AVS all
verify  and there are no other outstanding problems  then the
request comes back approved. The "age" authentication services typically
are registering individuals by requesting the information to perform a "one
dollar auth"  where there is no subsequent batch submission for actual
funds tranfer.  If the "one dollar auth" is approved, the age
authentication services take the result as indication of legal age  the
credit card owner needing to have been of legal age to have legally signed
the credit card contract and obtained the credit cad in the first place.
Since no funds transfer actually takes place, nothing shows up on the
consumer's credit card bill. The age verification service is charged a very
nominal transaction fee for the "one dollar auth" (along with the AVS
transaction).

The age verification service then just packages that one time charge into
the fees that they charge their customers. They effectively maintain a
local "cache" of the answer to the "one dollar auth" transaction.

I would contend that the evidence that such things are going on today ...
is that the current system is "open" in the sense that it has open
standards (like ISO 8583) and lots of entities are making use of it.

In theory, one opportunity for FAST-like offerings is for the financial
industry to get directly into the age authentication service business (in
theory being able to do it at least as well with the data as the 3rd party
players out there today). A x9.59-like transaction can be defined  but
in place of "dollar amount", there are misc. other types of fields 
like "legal age". The consumer then digitally signs the transaction and
forwards it to the merchant or server. The server takes the transactions
and ejects it into the appropriate authentication network (very much like
credit card transactions are done today) and gets back a "YES/NO" answerr
(again very much like credit card transactions happen today)  the only
difference is instead of asking for consumer funds approval, the merchant
is asking question about legal age. Identity information isn't being
divulged ... not even date-of-birth ... which could raise a serious
identity fraud question  just answerring YES/NO to the legal age
question. It could look like an X9.59 transaction, taste like an X9.59
transaction ... but instead of having funds involved, it has legal age
involved.

It effectively creates an "open" online, authentication infrastructure ...
requiring consumer to digital sign the transaction  and a recognized
certification authority providing real time, non-privacy invasive, answers.
It otherwise has all the elements of an open public key infrastructure
(registration authorities, certification authorities, consumers, relying
parties, etc) w/o any certificates. In that sense it is an online PKI
paradigm  rather than the certificate-based offline PKI paradigm (which
emulates the pre-70s offline credit card infrastructure).




<[EMAIL PROTECTED]> at 12/26/2001 2:36 pm wrote:

in addition to the x9.59 for all electronic payment transactions ... it is
possible to extend online authentication where the institution possibly
isn't also responsible for the authorization (and/or access privileges)
things like FAST projects in FSTC:
http://www.fstc.org/projects/fastaggregation.cfm






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

Re: CFP: PKI research workshop

[lynn . wheeler]

again, why would the financial industry be interested in regressing (at
least) 30 years to a certificate-based offline model?

they do authentication of transactions that they also need to do
authorization for   in a model that has prior business relationship
between the parties. certificate-based PKI were targeted at offline email
genre of the early '80s and analogous to the offline credit-card model
pre-70s.

in addition to the x9.59 for all electronic payment transactions ... it is
possible to extend online authentication where the institution possibly
isn't also responsible for the authorization (and/or access privileges)
things like FAST projects in FSTC:
http://www.fstc.org/projects/fastaggregation.cfm




ray dillinger <[EMAIL PROTECTED]> on 12/26/2001 12:31 pm wrote:


In fact, that may be exactly it.  PKI, as espoused by vendors,
once established, will become an indispensable monopoly, like
AT&T before the breakup. Investors love the fantasy of buying
a kajillion shares for cheap today and then having them be
shares in an indispensable monopoly next year, so they are
inclined to believe.

The problem is that none of the vendors are offering anything
that someone who has significant volume (like a financial-services
company might) cannot provide for themselves.  The FS companies
can easily wait to adopt, because the margins offered by PKI are
fairly small and the initial investment required is fairly large.
Perhaps the margins will remain too small until royalty payments
can be eliminated entirely (until any patents expire) and the
FS companies can roll their own.  Whether or not the margins
are too small, The FS companies can wait that long easily.

But the PKI vendor cannot wait.  S/he will be out of business
in three or four years if nobody adopts.  The patents will be
for sale then much cheaper than the royalty payments s/he is
offering, and the FS negotiator across the table knows it.  The
PKI vendor therefore is going to get the worst end of the deal
every time s/he goes to financial services vendors, because s/he
is not dealing from a position of strength, and had best learn
the harsh lesson sooner rather than later.

A PKI will happen, eventually, but nobody is going to get into
a position where the financial-services sector depends on them
and has to pay them.  That's as fundamental in business as the
second law of thermodynamics in physics, and chasing the dream
of becoming an indispensable monopoly to the financial services
sector promises to be as frustrating to the seekers as the quest
for a perpetual motion device.

  Bear







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

Re: CFP: PKI research workshop

[lynn . wheeler]

possibly not the ATM you were thinking of  certificate-less digital
signature authentication by NACHA/ATM/debit networks
http://www.garlic.com/~lynn/index.html#aads

specific web page:
http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

financial industry standard for digital signature authenticated electronic
payment transactions for all payments (x9.59):
http://www.garlic.com/~lynn/index.html#x959

misc discussions regarding privacy and certificate-less digital signature
authentication
http://www.garlic.com/~lynn/subtopic.html#privacy




matt crawford <[EMAIL PROTECTED]> on 12/26/2001 8:20 am wrote:

As I never tire of saying, "PKI is the ATM of security."

Meaning that has a certain niche relevance, but is claimed by
proponents to be the answer to every need, and is the current magic
word for shaking the money tree.





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

Re: CFP: PKI research workshop

[lynn . wheeler]

note that the certificate-based PKI is an offline model  it is the
credit card model pre-1970. the certificate-based PKI tends to bear a lot
of other resumblance to pre-1970 offline credit-card model  the CRLs
invention is very similar to the paper booklets that were mailed out to
merchants every month of invalid credit card numbers (the credit-card
industry however had a significant advantage having a very strong
relying-party registration function  so that there was high probability
of relying-parties getting the paper booklets of invalid numbers).

in the '70s, the credit card industry switched from an offline
infrastructures (aka similar to the certificate-based PKIs which were
effectively developed to address the offline email infrastructure of the
early 1980s) to an online infrastructure ... where every transaction was
executed online. A certificate-based PKI for credit cards would be like
regressing 30 years to the offline infrastructure (although using more
convoluted and complex technology). The issue is why would the payment card
industry want to regress 30 years to an offline model with
certificate-based PKI?

The financial industry has passed an online payment definition that does
use digital signature technology w/o all the complexity and short-comings
of a certificate-based PKI  (that would set-back/regress the infrastructure
30+ years to the offline model)  which is X9.59.

Baiscally X9.59 defines a retail payment object that is valid for ALL
electronic online financial transactions (internet, non-internet,
point-of-sale, debit, credit, ACH, etc) which basically requires a digital
signature and does not require a certificate-based PKI.  The simplest
analogy is that digital signature technology upgrades the PIN-based
infrastructure found in current debit transactions and expands it to all
electronic financial transactions.

There have been some financial pilots using certificate-based PKI
operations  but in all cases it is relatively trivial to show that the
certificate is redundant, superfulous and extraneous in an online world.
The certificates were effectively relying-party-only certificates
(basically containing an account number and a public key)  in part to
meet liability and privacy requirements. Since only an account number was
used and the transactions &/or other operations were all online ... they
all referenced the account in order to execute the requested operation. It
is trivial to show that given online operation executioin (including things
like "logging in" for vaious kinds of things related to online banking
and/or other financial or securities industry transactions)  that is
superfulous to have the certificate.

The certificate makes sense in an offline environment where there is no
prior business relationship between the entities. Given online situations
involving parties with prior relationships, certificates make no sense.

misc. x9.59 references:
http://www.garlic.com/~lynn/indec.html#x959

misc certificate-less digital signature references (including pointers to
the NACHA/debit network implementation ... and a private key hardware token
description allowing the same private/public key to be used in an
arbritrary large number of different & public operations):
http://www.garlic.com/~lynn/index.html#aads

random client digital signature authentication refs:
http://www.garlic.com/~lynn/subtopic.html#radius

misc. discussion of certificate-based SSL domain name operation:
http://www.garlic.com/~lynn/subtopic.html#sslcerts




ray dillinger <[EMAIL PROTECTED]> on 12/26/2001 12:03 pm wrote:


Yep.  So far, that's true.  Financial stuff is the only killer app
in sight for a PKI, and the financial services sector is conservative
and heavily regulated.  There is a substantial barrier to entry: just
try to imagine running off a few thousand PKI-backed credit cards and
going into business competing against mastercard/visa/amex.  Vendor
acceptance is slow and the regulatory hurdles are high.



Odds are, however, that each and every one of them is going to want
their own PKI -- where P stands for Private, or Proprietary, rather
than Public.  A Public Key Infrastructure happens when the chaotic
situation which that brings about gets consolidated and standardized,
so don't look for that for at least a decade.  Basically we have no
chance of getting a Public Key Infrastructure in place right now
because we don't have enough different Private Key Infrastructures
in place for it to have started to hurt yet.  People won't go for
the PKI until they are in some kind of pain that it relieves. And
if financial services businesses are involved, they will do it in
such a way that no PKI vendor ever makes a profit they could possibly
have made themselves.  Look for them to be buying regulations that say
PKI is part of financial services and can only be provided by licensed
financial services corporations sometime in the next few years.

Like I said, don't g

Re: when a fraud is a sale, Re: Rubber hose attack

[lynn . wheeler]

but in the financial case ... you don't have to identify them (aka their
DNA) ... you just match them and the account. absolutely no identity
needed. If i deposit a large sum of money and want to be the only person
authorized to transact on the account ... there is no need to present
identity cards at all (fake or otherwise). Supposedly, swiss bank accounts
have worked that way in the past  totally authenticated transactions,
absolutely no identity. There are misc. other issue related to govs.
wanting valid identities involved ... but they are extraneous to the issue
of authenticating that the entity attempting to transact on the account is
actually the entity authorized to transact on the account. There can be a
extremely high level of confidence in an authentication system as to the
entity attepting a transaction is the entity authorized to do a transaction
and absolutely no identity information need to be involved. Identity
information may come into play with regard to financial accounts  but
they can be totally extraneous to authenticating valid transactions.

In fact, one of the issues with regard to "relying-party-only" certificates
(mentioned in previous post)  was 1) institutions not wanting to take 3rd
party liability and 2) all identity information was totally eliminated from
the certificate ... leaving just the account number. This was specifically
because it was an invasion of privacy that extraneous parties (like
merchants) that the transaction might pass thru (and its end-to-end route)
might examine the information;  besides the identity information being
totally extraneous and superfulous. That is a separate issue from also
being able to show that just attaching such a credential was unnecessary,
superfulous, redundant and extraneous (futhermore a credential that doesn't
exist is even more private than a credential that has had all the
interesting information removed).




[EMAIL PROTECTED] on 11/05/2001 11:15 AM wrote:


The real trick is identifying the person the first time. The person is a
stranger and the person trying to identify them couldn't tell a fake ID
from
a real one.

John







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

Re: when a fraud is a sale, Re: Rubber hose attack

[lynn . wheeler]

not completely. except for some of the "know your customer rules"  a
financial institution doesn't have to identify you ... they only have to
authenticate that you are the person authorized to transact with the
account; aka 1) I come in and open a brand-new account and deposit a whole
lot of money. 2) they give me a card with possibly PIN which is the only
way that is enabled for authorized transactions. They may also record some
number of shared secrets as a fall-back position (some of the
shared-secrets may involve identity information ... but that is more of a
memory mnemonic, i know people that register almost random shared-secrets
that have no relationship to their identity). No identity is involved.
Governments may require identity for other reasons ... but it is possible
to establish that it is the entity authorized to make transactions w/o
requiring any identification (using purely authentication).

That is not to say that there are various kinds of fraud involving things
like identity theft ... but it is possible to authenticate transactions w/o
requiring identity.

There are some other issues with some infrastructures involving trusted
third parties (TTPs).

I've gone into some length with regard to the discussion of TTPs and domain
name web server certificates ... aka
http://www.garlic.com/~lynn/subtopic.html#sslcerts

where, in effect because of concerns over the integrity of the domain name
infrastructure, digital certificates have been introduced. Note however,
TTPs normally are not the recognized authoritative entity with regard to
domain names  TTPs just "certify" that they've checked with with the
authoritative entity with regard to whatever they are certifying when they
manufactor the digital certificate.

Now, who is the authoritative entity for domain name information that TTPs
check with when they are manufactoring a domain name web server
certificate? It is the domain name infrastructure. As a result of integrity
concenrs there are also integrity concerns with regard to the domain name
infrastructure from TTPs (because they effectively rely on the same
authoritative agencies that people are concerned about with regard to
normal operation). Now the interesting part is that there are proposals
that would fix the integrity problems of the authoritative domain name
agency ... the domain name infrastructure  however, if those proposals
were implemented, it would also correct integrity concerns regarding the
domain name infrastructure for the rest of the world ... elminating the
desire they have to have domain name web server certificates as a means of
compensating for the integrity issues with the domain name infrastructure
(which is also the authoritative agency for domain names that the TTPs
check with in order to certify domain names in manufactored certificates).



[EMAIL PROTECTED] on 11/05/2001 10:01 AM wrote:

I think you have nailed it on the head. When authentication is viewed as
the
"first link" in the chain instead of identification. The problem with all
authentication technologies in use today from biometrics to PKI to digital
certs, all finesse the identification process and push it off to some
"trusted" third party...all without clearly defining what that third party
must bring to the table.

John






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

Re: when a fraud is a sale, Re: Rubber hose attack

[lynn . wheeler]

slight aside, in beginning security basics end-to-end typically means that
a authorization or service message requiest  . originates with the
requester and has been secured with authentication and/or encryption of the
requester and travels end-to-end from the requester to the service entity
... which first validates the authorization/service request (based on the
end-to-end authentication and/or encryption from the requester) and then
returns an authorization or some other indication that the service is
performed.

most beginning security basics teach that if authorization and/or service
request does not have end-to-end security and/or integrity then the design
is fundamentally flawed and opportunities for fraud is created.
An example is that in SET, the card-holder/consumer's authentication
information was stripped off at some random internet gateway and a flag
inserted in an otherwise normal iso 8583 financial transaction message
claiming that digital signature authentication had been performed. A year
or so after SET pilots were in operation, somebody from VISA gave a
presentation at some ISO meeting in europe detailing the percentage of iso
8583 messages where the "authenticated" flag  had been turned on by some
entity (and for which the consumer's issuing bank was now suppose to base
various business processes and decisions) and they could positively show
that no internet payment and/or any other form of digital signature
authentication was involved (aka no end-to-end entegrity and/or security).

in the account-based financial transaction ... the requestor is the
card-holder/consumer and the authorization or service entity is the
card-holder's financial institution.





   
JohnE37179@aol.
com To:  [EMAIL PROTECTED],   
   [EMAIL PROTECTED], [EMAIL PROTECTED]  
 11/05/2001 cc:  [EMAIL PROTECTED],   
   08:49 AM[EMAIL PROTECTED], 
   [EMAIL PROTECTED],
   [EMAIL PROTECTED]   
Subject:  Re: when a fraud is a sale,  
   Re: Rubber hose attack  
   





In a message dated 11/5/01 9:41:44 AM, [EMAIL PROTECTED]
writes:

<< On one hand I'm tempted to read this as a plea for some absolute
notion of security, but somehow I don't think that's really what
you're saying. >>

Rick, my point is that VISA and to a slightly lesser extent, MC, have built
a
model just as you describe: send the money, but we don't take any risk.

I tend to agree with you that we should extend the meaning of end-to-end to

mean user-to-user, instead of device or token-to-token.

John







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

Re: Rubber hose attack

[lynn . wheeler]

i believe i said that ROI represented the total cost of the program to
eliminate some fraud  compared to the total amount of fraud. in the credit
card scenerio it isn't enuf to know the cost per event. assuming that
adding chips to those payment cards is a solution. in there US there are
something less than a billion new cards sent out each year ... and adding a
chip could cost on the order of $25 each. Just for the chips (ignoring for
the moment the issue of reader provisioning) ... that cost might be
somewhere in the $15b to $20b per annum range. There would have to be a
huge number of $3500 per fraud events eliminated by a comprehensive chip
program to justify it.

so as referenced in the previous postings  advances in technology can
reduce the cost of dealing with fraud (in the chip card case ... it would
be nice to reduce it from $20b/annum to maybe under $1b/annum; say a
combination of significantly reduced chip costs as well as the number of
new sent out each year) while at the same time increasing the amount of
fraud (criminals find it easier to counterfiet existing cards increasing
the amount of traud that happens).

However, generically (except for some specific exceptions), the majority of
fraud has tended to be insider fraud. Just improving things with strong
authentication &/or identification doesn't directly address insider fraud,
significant audit, command & control, and compensating procedures are
needed to be in place to address significant amounts of insider fraud (who,
effectively by definition, have already been authenticated and identified).




[EMAIL PROTECTED] on 11/02/2001 08:26 pm wrote


Again, this is only a very small part of the problem. The Inspector
General's
office reports that the average identity fraud in the Social Security
Administration costs over $100,000. Texas Medicaid loses approximately 25%
of
its $4 billion budget to fraud. The ABA reports that the average cost of
each
credit card fraud for the issuer exceeds $3500. Each incident of identity
fraud in recruiting costs DOD over $500,000.






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

Re: Rubber hose attack

[lynn . wheeler]

the following from a thread on some of the fees related to fraud issues at

http://lists.commerce.net/archives/internet-payments/200110/maillist.html

specifically from a thread on Visa/MasterCard Antitrust Comments.

Here's an interesting quote taken directly from Judge Barbara Nelson's
decision (the full text of the decision is available at:

):

"Defendants' ability to price discriminate also illustrates their market
power.

Both Visa and MasterCard charge differing interchange fees based, in part,
on the degree to which a given merchant category needs to accept general
purpose cards.

Transactions with catalog and Internet merchants, for example, which rely
almost completely on general purpose cards, have higher interchange fees
than 'brick and mortar' merchants.

Defendants rationalize this difference by pointing to increased fraud in
these merchant categories, but this explanation is belied by the fact that
the Internet merchant, not Visa/MasterCard or their member banks, bears
virtually all the risk of loss from fraudulent transactions.

Even today, Amazon's fraud rate is lower than mail-order companies, yet it
is charged (indirectly, through the merchant discount) the same interchange
fee as these mail order companies.

The reality is that Visa and MasterCard are able to charge substantially
different prices for those hundreds of thousands of merchants who must take
credit cards at any price because their customers insist on using
those cards."




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

Re: Rubber hose attack

[lynn . wheeler]

also a somewhat related thread regarding costs for stronger authentication
technology

http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip
Market





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

Re: Rubber hose attack

[lynn . wheeler]

slight clarification  while consumers don't directly pay the
transaction fees ... whatever fees that the merchants directly pay ... show
up in prices that come out of consumers pocket-book ... which they do pay
... as well as various & sundry fees that consumers pay to their issuing
bank as part of various credit related fees & charges.

parts of the issue has always been would the procedures to lower fraud,
cost more than the fraud they were limiting. Two things have been happening
... the cost of technology has in general been coming down rapdly ... both
the cost of technology needed to limit fraud as well as the cost of
technology for various kinds of fraud & counterfeiting (which tends to
increase the amount of fraud).

misc threads on the subject
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm6.htm#terror14 [FYI] Did Encryption
Empower These Terrorists? (addenda to chargebacks)
http://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate?
(addenda)
http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital
Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card
fraud"
http://www.garlic.com/~lynn/aepay6.htm#ccfraud3 "out of control credit card
fraud"
http://www.garlic.com/~lynn/aepay7.htm#fakeid Fake IDs swamp police
http://www.garlic.com/~lynn/2000f.html#64 Cryptogram Newsletter is off the
wall?
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit
cards!
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001j.html#9 E-commerce security

credit has enjoyed quite a bit of market penetration in terms of internet
transactions ... in part because it was relatively simple to adopt the
existing MOTO-model to the internet

http://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and
some x9.59 ... fyi
http://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and
some x9.59 ... fyi
http://www.garlic.com/~lynn/aadsm5.htm#asrn1 Assurance, e-commerce, and
some x9.59 ... fyi
http://www.garlic.com/~lynn/2001i.html#52 loosely-coupled, sysplex,
cluster, supercomputer & electronic commerce

however, x9.59 which had a requirement to preserve the integrity for all
account-based transactions in all envrionments with only authentication ...
also opens up other payment methods to the internet (as well as general
ability to reduce fraud)

http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm
NACHA AADS results!!
http://www.garlic.com/~lynn/index.html#aads

with regard to to rubber hose attack ... there is an issue of ROI (assuming
a rubber hose attack has some rational financial motivation as opposed to
something akin to random violence) ... i.e. effort to mount the attack
vis-a-vis reward in return. The discussion of stealing a web merchant
credit card master file may have a relatively modest investment but result
in several hundred thousand account numbers for which fraudulent
transactions can be executed against.  The claim is that ROI for rubber
hose attacks would preclude majority of rational financial motivation ...
aka they're would be other attacks with signficiant better ROI. While
rubber hose attacks might never totally disappear ... the amount of fraud
from such events will be very small.

misc. past threads in the area:
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server
security
http://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower
These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror4 [FYI] Did Encryption Empower
These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
http://www.garlic.com/~lynn/aadsm6.htm#pcards3 The end of P-Cards?
(addenda)
http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe??
... security proportional to risk
http://www.garlic.com/~lynn/aepay7.htm#netsecure some recent threads on
netbanking & e-commerce security
http://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay7.htm#3dsecure3 financial payment
standards ... finger slip
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#67 Would this type of credit card
help online shopper to feel more secure?
http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
http://www.garlic.com/~lynn/2001i.html#57 E-commerce security
http://www.garlic

Re: AGAINST ID CARDS

[Lynn . Wheeler]

slight note ... id-card-scanners at airports isn't really a cost issue, it
is the cost/benefit of using them. most of the airlines have put in the
gate scanners that are either mag-stripe and/or bar-code readers (the
overall station cost drawfs the specifics of the actual reader part of the
cost). some of them have also done extensive testing of  7816 contact
chip-card readers. the problem with 7816 chip-card readers in high-traffic
& transit applications is that they have very poor reliability and bad
failure characteristics (for instance readers can develop burs on the
contacts which rips the contacts on the card ... not only does the reader
fail ... but it takes some number of cards with it). europe is starting to
see some conversion from contact-card infrastructure to proximity chip
cards (because of the reliability issue of contact chip-card readers)  ...
similar to the kind you see in Wash DC (and other) metro stations (again
the gate/station cost is significantly higher than the specifics of any
card reader costs ... and still can be deployed in even lower-value metro
uses).

some of the financial stored-value chip-card value propositions were
primarily to the operators having the float (aka you paid money to the
operators which they deposited in interest bearing accounts, and they then
gave you a non-interest-bearing credit in your card). that restricted value
proposition may be one of the reasons that they have had lower success.
However, by comparison there is pretty wide deployment and use in the US of
magnetic-stripe stored-value cards (filling the same market niche as the
chip-card stored value cards)  common deployment is as "gift cards" on
j-hooks at check-out counters in many department, drug, convinience, etc
stores.

there is the story about one of the stored-value contact card operators
making a presentation at a transit meeting. They explained that they could
meet the turnstyle transversel rate by having a 10 foot "tunnel" leading up
to the turnstyle ... the contact card would be loaded into a RF contactless
"carrier" and if the people were forced to walk slowly thru the tunnel, the
transaction could just about be completed before they reached the
turnstyle.




Carl Ellison <[EMAIL PROTECTED]> at 10/07/2001 8:23 AM wrote:


   So, I think we have a harder problem than we thought we did --
but I
also think that the opposition does, too.  Issuing national ID cards
would be expensive and would meet much resistance from the US
population.  Installing "ID-card-scanners" would be even more
expensive, perhaps enough to stop that step from happening.  (Seen
any Mondex card scanners lately?) Building the underlying database
mechanism would be far more expensive and would meet far more
resistance, but it's not until you do the second that you have any LE
value or any privacy threat at all.  If all you do is ask for the ID
card and don't check it, you encourage stupid uses (and therefore
identity theft).






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

Re: [FYI] Did Encryption Empower These Terrorists? (addenda to chargebacks)

[lynn . wheeler]

Basically there are chargeback rules for card holder present, card present,
as well as ability to read track 1&2 (on mag. stripe). One of the issues is
that even in card present scenerios with indication that trace 1&2 could be
read, there are starting to be counterfeits and fraudulent transactions:
http://www.garlic.com/~lynn/aepay6.htm "out of control credit card fraud"

In the X9.59 scenerio using something along the lines of an AADS card:
http://www.garlic.com/~lynn/aadsm2.htm#straw

there is plauseability that it could represent "stronger" authentication
than current card present (i.e. much harder to counterfeit) even when
non-face-to-face, MOTO, &/or internet transactions are involved.

However, fraudulent transactions (either in MOTO/internet scenerio or card
present ... because of short-comings in strength of authentication) still
doesn't account for all the reasons for charge-backs &/or disputes ... aka
even given absolute perfect authentication and no (consumer) fraudulent
transactions ... there are still reasons for charge-backs and/or disputes.

ref:
http://www.garlic.com/~lynn/subtopic.html#publickey





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

Re: [FYI] Did Encryption Empower These Terrorists?

[lynn . wheeler]

I'm not sure I understand. A lot of the association credit regs have to do
with establishing consumer confidence & trust when dealing with totally
unknown merchants. Disputes/chargebacks can be more than "I didn't perform
that transaction" (mostly because it is so easy to execute
non-authenticated fraudulent transactions) ... there are a whole variety of
disputes/chargebacks having to do with non-delivery &/or non-performance
... i.e. even in credit card & card holder present situations;  In fact,
there is the whole scenerio referenced previously where airline tickets are
bought with a credit card and the airline goes bankrupt ... the acquiring
bank is then liable.
http://www.garlic.com/~lynn/aadsm6.htm#terror9

even with authenticated transactions there are still some aspects of
MOTO-transaction reg (mail-order, telephone-order) that could still apply
... for instance, in the case of hardgoods, your account is not to be
billed until goods are actually shipped. there is still the scenerio that
goods never shipped.

if disputes/chargebacks were to be totally eliminated for authenticated
transactions then (x9.59) credit & debit would really be put on a totally
level playing field ... also discussion
http://www.garlic.com/~lynn/aadsm6.htm#terror9

note that there are some basic security 101 principles that can be applied
here  ... as done by X9.59 ... whenever there isn't end-to-end continuous
security & end-to-end continuous, seemliess authentication (say when it is
split into multiple different operations and transactions and not a single
seemless operation) then there are bound to be gaps & cracks in the
security  into which fraud can creep 




"Enzo Michlangeli" <[EMAIL PROTECTED]> on 9/26/2001 5:26 PM wrote:

That's 3D Secure's job (see above). Once the issuer has authenticated the
cardholder, neither merchant nor acquirer can be held responsible for
chargebacks: the issuer pays, and then deals with its cardholder as it
deems
fit. (If you want my opinion, the very reason why Visa developed 3D Secure
is that they are sick of being involved in the dispute resolution process).







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

Re: [FYI] Did Encryption Empower These Terrorists?

[lynn . wheeler]

__

note that X9.59 standards work spent quite a bit of time attempting to
minimize the number of places that identity might have to occur. In general
an X9.59 account number can be related to a person (i.e. possibly bank regs
related to "know your customer"). It attempts to only do strong
authentication with digital signature ... but leaving as few identity
fingerprints as possible (at least as far as the financial transaction is
concerned). Also, strongly authenticated transactions significantly reduces
the possibility that fraudulent transactions have occured.

Also, since X9.59 standard was to be applicable to all account-based
transactions ... it had to be agnostic with respect to identity information
to cover financial transactions that didn't have the rules and regulations
associated with credit ... say debit and/or even "stored value" (say a
digitally signed version of those "gift cards" that are frequently found at
check-out stands at places like blockbuster, sears, etc).


Ray Dillinger <[EMAIL PROTECTED]>  at 9/26/2001 10:06 AM wrote:



A few problems:

1) in a typical credit card transaction, the seller neither knows,
   nor cares, what bank issued the credit card.  Thus, connecting
   to the correct gateway becomes a minor problem.

2) No provision for dispute resolution.  What happens in a month
   and a half when george gets his credit card bill back and says
   "I've never been there and never done any business with this
person"?  The bank generates a chargeback and sends it to the
merchant who, in the absence of knowledge about the buyer's
identity, has no recourse.  George may or may not be the person
who made the transaction; but the merchant has no way to even
begin to try to find out.


In general, "anonymity" and "credit" are immiscible.  If you want
anonymous transactions, you absolutely cannot abide by the laws
that require chargebacks, merchant and/or bank liability in case
of fraud (instead of consumer liability), etc.  Compliance with
those laws requires the merchant and banks to have the very
information that anonymity prohibits them from having.

For anonymous transactions, you want something a whole lot more like
cash, with the same failure modes (ie, no shift of liability in case
of fraud) as cash.  That requires infrastructure which will not be
allowed to be built.






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

Re: [FYI] Did Encryption Empower These Terrorists?

[lynn . wheeler]

one slight distinction from ansi/iso standards body perspective  SET
was an industry specification not a standard ... and in fact at one point I
believe there was some statement that SET was never going to be submitted
for standardization consideration.





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

Re: [FYI] Did Encryption Empower These Terrorists?

[lynn . wheeler]

misc discussion regarding SET NEVER intended to hide PAN from the merchant
(in part because, a merchant gets dispute notification directly from the
consumer's bank with the only reference being the PAN, the date, and the
amount).

http://www.garlic.com/~lynn/2001h.html#38 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#39 Credit Card # encryption
http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
http://www.garlic.com/~lynn/aepay4.htm#comcert3 Merchant Comfort
Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort
Certificates
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re:
crypto flaw in secure mail standards

note that the issuing (consumer) bank and the acquiring (merchant) bank
don't necessarily have the same interests. in the standard SET scenerio,
the only thing that the issuing bank sees is a flag in an 8583 message
saying that some internet gateway someplace may have correctly
authenticated a digital signature on a SET transaction. there is no
end-to-end security and/or authentication. about a year into some of the
SET deployments, somebody from VISA gave a presentation at an ISO meeting
in europe on the number of 8583 transactions arriving at an issuing bank
with the SET signature verified flag turned on and they could proove that
both the merchant, any gateway, and the acquiring bank had absolutely zero
SET and/or other digital signature technology (the flag was just being
set).

Part of the issue was that the size bloat of a SET transaction compared to
a normal 8583 transactions could approach two orders of magnitude  in
part resulting in the gateway performing the signature authentication and
then throwing away everything and just setting a flag in the 8583 message
claiming that the authentication was performed.

Part of the x9.59 standard design point was to be light-weight enuf so that
there could be real end-to-end security with real end-to-end authentication
that actual flows with the real transaction (that was also in part derived
from the requirement that x9.59 standard could be applied to all
account-based transactions, regardless of internet, point-of-sale, debit,
credit, existing infrastructure, new infrastructure, etc).

In the x9.59 standards scenerio, the merchant doesn't even need SSL
technology (at least not for integrity/fraud reasons, some people may still
prefer SSL ... but it would be a privacy issue, not a fraud & integrity
issue). The merchant gets a couple more data elements which must be mapped
into X9.15 (or the 8583 subset equivalent) for sending directly to their
acquiring processor. The processing would be exactly the same for an
internet web site as for a point-of-sale terminal. The processing would
also be the same whether it was debit or credit (except for possibly
X9.15/8583-subset protocol differences between their credit processor and
their debit processor ... if any).

misc. past discussion regarding real end-to-end security
ttp://www.garlic.com/~lynn/aadsm2.htm#integrity Scale (and the SRV record)
http://www.garlic.com/~lynn/aadsm2.htm#privacy Identification and Privacy
are not Antinomies
http://www.garlic.com/~lynn/aadsm2.htm#keylength On leaving the 56-bit key
length limitation
http://www.garlic.com/~lynn/aadsm2.htm#keyl2 On leaving the 56-bit key
length limitation
http://www.garlic.com/~lynn/aadsm2.htm#keyl3 On leaving the 56-bit key
length limitation
http://www.garlic.com/~lynn/aadsm2.htm#techno digital signatures,
technology experiments, and service operations
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1
vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk
Management and Information Security
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations
regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments
on X9.59 issues.
http://www.garlic.com/~lynn/aepay3.htm#privacy misc. privacy
http://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from
usenet group
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information
... summary
http://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA /
draft X9.59
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment
standard issue
http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark
Debate
http://www.garlic.com/~lynn/ansiepay.htm#x959ansr Comments from 2nd LB on
DSTU X9.59
http://www.garlic.com/~lynn/ansiepay.htm#anxclean Misc 8583 mapping cleanup
http://www.garlic.com/~lynn/99.html#240 Attacks on a PKI
http://www.garl

Re: [FYI] Did Encryption Empower These Terrorists? (addenda)

[lynn . wheeler]

using x9.59 for all account-based transactions would put debit & credit on
a level playing field with regard to authenticated transactions (and
promotes debit use over the internet).

besides the significant difference in merchant cost infrastructure between
the two ... the other remaining difference is the significant difference
with regard to consumer recourse between the two ... i.e. credit has a lot
of regs that effectively allow consumer to "trust" a transaction (not only
based on trust in the merchant, but also in the merchant bank and the
consumer bank) ... even a merchant that the consumer has had no prior
knowledge and/or dealings with. This has been touted as a significant
factor on the internet with the non-face-to-face characteristic of the
consumer/merchant relationship and any consumer anywhere in the world could
do business with any merchant anywhere in the world, aka the credit regs
with regard to consumer recourse infrastructure providing significant
benefit in such an environment (with merchant, merchant bank, consumer bank
all having various levels of responsibility ... even in the case of a
merchant going bankrupt; a significant issue for merchant banks with regard
to credit is airline tickets ... a significant fee source, but also can be
a major liability if the airline goes bankrupt).

however, with regard to the internet trust issue ... the consumer
e-commerce transactions don't have a random, homogeneous distribution
between all consumers and all merchants ... the distribution tends to be
quite skewed with possibly 20-30 locations accounting for 60-70 percent of
all transactions and possibly 100 locations accounting for 90 percent of
all transactions. There is much less of an "unknown" issue involving
transactions with the top tier well-known merchants that everybody
frequents as well as individual consumers having done multiple transactions
with the same merchant(s) in the past. In this scenerio (for possibly 90
percent of internet transactions) there is much less of a difference
between credit and debit with regard to the consumer not knowing and/or
having no knowledge on which to base "trust" in the merchant. In the
situation involving possibly 90+ percent of internet e-commerce consumer
transactions the consumer would tend to have very little difference in the
level of amprehension with regard to using either (x9.59) credit or (x9.59)
debit for the transaction.

Credit (either x9.59 or not) would still provide a consumer perceived
advantage when dealing with the vast majority of the internet merchants
that account for relatively trivial percentage of all transactions (aka
rather than just judging whether they trust just the merchant, they can
also rely on the trust in their consumer bank as well as possibly in the
associated merchant bank).

random refs:
http://www.garlic.com/~lynn/aadsm2.htm#useire2 U.S. & Ireland use digital
signature
http://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An
Artifact...




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

Re: [FYI] Did Encryption Empower These Terrorists?

[lynn . wheeler]

what I (attempted?) to say was that the "typical" merchant and or
"typically" at merchants ... the account number file is vulnerable and
frequently is also on the same system as that running the web server. The
original/first implementation had the account file and the transactions
performed on a separate back-end system. That original implementation
didn't become the prevailing deployed operational infrastructure.
It doesn't matter that the original implementation of a separate back-end
system was better or worse ... it didn't prevail.

In general, the harvesting of the account number master file is a major
vulnerability ... whether it is on the same system or a different system.
Moving it to a different system may or may not make it less vulnerable to
harvesting by internet-mounted attacks. Mostly, in the past, "insider"
attacks have been considered 90% of the vulnerability problem (although
recently internet-mounted external attacks get more of the press).

For the very first implemetation, we believed we had an implementation for
back-room credit card transactions that was significantly less vulnerable
to internet-mounted attacks. The point was that is not what prevailed and
is not what is commoningly deployed.


ben laurie <[EMAIL PROTECTED]> wrote:

It is easy to avoid this piece of bad design, for example by
transferring asymmetrically encrypted order details to a back-end system
(via email is a popular choice).

Of course, the system is still vulnerable to trojan-style attacks (in
fact it seems to me that even this could be avoided with some cunning
client-side work - it would even be valuable to extend, say, SSL to
permit this - I wonder if it would be worth describing how this could be
done?).

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



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







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

Re: [FYI] Did Encryption Empower These Terrorists?

[lynn . wheeler]

note that financial standard body
http://www.x9.org/


in the financial standards body has passed X9.59 standard for all
electronic account-based payments that uses digital signature for
authentication (and has business rule that account numbers used in
authenticated transactions are not valid in non-authenticated
transactions). As a result, account numbers are eliminated as a point of
attack. In the past, while there may have been protocols that encrypted
transactions and/or authenticated transactions, the business rules for the
account numbers didn't change, so the account number master file remained a
point of exploit. The ISO 8583 field for carrying the X9.59 data has also
passed at the international level (ISO8583 is the international standard
for the backbone ATM, debit, and credit networks).

misc. refs to x9.59
http://www.garlic.com/~lynn/

X9.59 is applicable to internet, point-of-sale, debit, credit, etc ... aka
ALL account-based transactions. Work had started on X9.59 in the '96
time-frame in
the X9A10 work group which was given the charter of a standard that
preserved the integrity of the financial infrastructure using only
authentication that was applicable to all account-based transactions. Many
of the issues was coming up with a light-weight, strongly authenticated
transactions that would have minimal impact on the existing infrastructure
and could be applied to all transactions. Much of the X9.59 standardization
activity was going on at the same time as some of the corporate
specification work (aka there is a difference between a corporate
specification and a financial body standard)

Having been involved in the original e-commerce deployments
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

and in some of the original deployments of some of the corporate
specification implementations ... convenience wasn't the only downside
issue. One of the issues was what incremental advantage did they provide?
i.e. both provided encryption of transaction in flight, but neither
provided any protection against harvesting of account numbers at rest.

In the credit case, it isn't even necessary to change the business rules,
putting the burden of proof on the consumer ... since much of the problem
has been using harvested credit card numbers in fraudulent unauthenticated
transactions. Since X9.59 defines only authenticated transactions ... it is
no longer possible to harvest x9.59 credit card numbers and use them in
fraudulent unauthenticated transactions (which has been major fraud and
exploit up until now).

NACHA/Internet council has finished such a trial with debit and some
members are progressing with production deployment. X9.59 would eliminate
many of the differences between credit and debit ... making both the same
strongly authenticated transaction.

misc. nacha refs:
http://www.garlic.com/~lynn/aadsm6.htm#echeck Electronic Checks
http://www.garlic.com/~lynn/aadsm6.htm#aadsatm (certificate-less) digital
signatures can secure ATM card payments on the internet
http://www.garlic.com/~lynn/aadsm6.htm#ppsem1 Payment Processing Seminars
http://www.garlic.com/~lynn/aadsmore.htm#nacha NACHA digital signature
pilot
http://www.garlic.com/~lynn/aadsmore.htm#debitfraud Debit card fraud in
Canada
http://www.garlic.com/~lynn/aepay6.htm#ecomich call for new measures: ICH
would be glad to help
http://www.garlic.com/~lynn/aepay6.htm#userauth MS masters NC mind-set
(authentication is the key)
http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nacha Nacha reports mentions X9.59
payment protocol
http://www.garlic.com/~lynn/aepay7.htm#visadeb1 Visa Debit Card
http://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe??
... power to the consumer
http://www.garlic.com/~lynn/ansiepay.htm#aadsach NACHA to Test ATM Card
Payments for Consumer Internet Purchases
http://www.garlic.com/~lynn/ansiepay.htm#atmdebit NACHA AADS ATM debit ...
from tomorrow's american banker
http://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI
(world-wide retail banking) show
http://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this
week
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#36 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001h.html#37 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001j.html#0 E-commerce security
http://www.garlic.com/~lynn/20

Re: [FYI] Did Encryption Empower These Terrorists?

[lynn . wheeler]

re: easy;

almost 30 years ago, we shot a scripting type virus on the internal network
and then laid down some "easy" rules that would preclude any new scripting
virus &/or trojan horses.

if it really was as trivial and easy as we thot 30 years ago ... by
definition, the majority of the recent rash of exploits, viruses, et al ...
would never have happened. Since the expolits did  happen (and are
continuing)  ... then there must be issues involved that are not be quite
as easy as we thot 30 years ago.

i spent some amount of my young years around various types of farm
equipment and thot it was easy living thru it (although when I was around
10,  i  let lady-fingers explode in my hand & when I was older ... worked
re-bar w/o gloves). Later, along came HEW and set out guidelines that a lot
of the stuff I grew up working around was dangerous equipment and in
various cases needed substantial modifications (what I thot was easy at the
time, subsequently was judged very dangerous).





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

Re: [FYI] Did Encryption Empower These Terrorists?

[lynn . wheeler]

If it was so easy ... it wouldn't be a problem. An objective of the
original e-commerce deployments was that the account number file not be
co-located on the webserver. Since a large number of subsequent deployments
have co-located on the webserver or on some equally accessable location
would tend to indicate that it isn't as easy as it might first appear.

One might suspect that the definition of "easy" is rather relative ... and
also there may be some questions regarding what aspect of the issues does
"easy" apply to (internet easy, server easy, webserver easy, technology
easy, programming easy, business process easy, process easy, etc).

I would claim that having it become so prevalent after the initial
subsequent deployments would imply that there are at least some issues
involved that make it much more than a simple, straight-forward, brain-dead
matter (if it was trivially obvious for everybody in world, then there is
some rational that nobody would have done in such a way that creates such
security & risk issues).




   
 Ben Laurie
<[EMAIL PROTECTED] To:  [EMAIL PROTECTED]
   .uk> cc:  [EMAIL PROTECTED],   
   Hadmut Danisch <[EMAIL PROTECTED]>, 
 09/24/2001[EMAIL PROTECTED]   
   01:32 PM Subject:  Re: [FYI] Did Encryption 
   Empower These Terrorists?   
   




[EMAIL PROTECTED] wrote:
>
> there are all sorts of shortcomings in this world. you find a "merchant"
> that buys a computer, installs some webserver software and puts it up and
> the web and expects that to handle everything.

Fine, but that was not the point you claimed to be making. You said:

> The web server
> account number master file also typicall represents a risk that is
> significantly greater than what typical merchant otherwise has at risk
...
> making it difficult to support a solution where the level of
> security/protection is proportional to the risk

but that is simply not true - it is very easy to eliminate this
particular piece of crap design.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff







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

Re: [FYI] Did Encryption Empower These Terrorists?

[lynn . wheeler]

of course, the other problem is that a substantial part is the "customer at
risk" (not just merchant at risk exposure as the result of any merchant
implementation short comings)  and there is currently no obvious way
that a customer can determine what, if any, security standards a merchant
might have implemented.

as mentioned in the various previous references ... what is at risk  ...
effectively proportional to the aggregate of the account credit limits ...
for all accounts that happened to have been stored in any account master
file ... is significantly larger than any particular merchant may have
directly at risk because of a security breach. in the "security
proportional to risk" theory  the entity that has the risk should have
control over the security measures, those security measures should be
proportional to what they have at risk, and the cost of those security
measures should also be proportional to the risk.

A complex, multi-system internet web implementation may represent a
significantly greater cost than the direct busines value a merchant may be
doing on the internet (not to mention the cost of the care and feeding of
such an implementation).  I would claim that any impression that such an
implementation is required is proof that what is at risk (value represented
by the account master file) is not directly related to what any merchant
might have at risk with putting up a merchant web server. Furthermore, I
would claim that it would be possible to find account master files
(regardless of the volume of a merchant's internet business) that
represents a risk level higher than the merchant direct risk ... and
therefor there will always be merchants (at all business size segments)
that find it difficult to provide security proportional to that risk.







This is simply bad design - there should be no "account number master
file" on the web server!

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



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







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

Re: [FYI] Did Encryption Empower These Terrorists?

[lynn . wheeler]

there are all sorts of shortcomings in this world. you find a "merchant"
that buys a computer, installs some webserver software and puts it up and
the web and expects that to handle everything.

there are sometimes prevalent things like that in the world; it would be
nice if people would choose a random 16-character value for every
PIN/password they need, that every PIN/password they have is different,
that every password/PIN changes at least monthly, and that every person
could easily remember one or two hundred 16-character random values that
change monthly, and no PIN/password is ever re-used.
misc. pin/password ref:
http://www.garlic.com/~lynn/2001d.html#52

security proportional to risk:
http://www.garlic.com/~lynn/aepay7.htm#netbank2

misc. information security & risk management:
http://www.garlic.com/~lynn/aepay3.htm#riskm
http:/www.garlic.com/~lynn/aepay3.htm#riskaads

misc. web refs:
http://www.garlic.com/~lynn/2001j.html#5
http://www.garlic.com/~lynn/subtopic.html#fraud
http://www.garlic.com/~lynn/subtopic.html#privacy

part of above posting 


when we were working on the credit card transaction stuff (now frequently
referred
to as electronic commerce):
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

we tried to get various security measures specified:

* physical security for the data processing room, motion detecters, guards,
etc
* multiple layers of firewalls & packet filtering routers
* actual financial transactions performed on backroom dataprocessing
  equipment away from the actual web server
* fbi background checks for all employees
* security audits
* minimum business & security certification levels.

... didn't happen, oh well.



   
 Ben Laurie
<[EMAIL PROTECTED] To:  [EMAIL PROTECTED]
   .uk> cc:  [EMAIL PROTECTED],
   [EMAIL PROTECTED], Hadmut  
 09/24/2001Danisch <[EMAIL PROTECTED]> 
   02:34 AM Subject:  Re: [FYI] Did Encryption 
   Empower These Terrorists?   
   




[EMAIL PROTECTED] wrote:
> The problems, of course are 1) account numbers are essentially shared
> secrets, 2) SSL only provides for protection for numbers in flight, 3)
the
> numbers at rest remain a major exploit (as per press stories regarding
> copying of account number master files at web servers) ... aka the use of
> SSL/ecryption only addressed a small portion of the problem. The web
server
> account number master file also typicall represents a risk that is
> significantly greater than what typical merchant otherwise has at risk
...
> making it difficult to support a solution where the level of
> security/protection is proportional to the risk

This is simply bad design - there should be no "account number master
file" on the web server!

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff







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

Re: [FYI] Did Encryption Empower These Terrorists?

[lynn . wheeler]

you may then also find "The Thread Between Risk Manaement and Information
Security" interesting

http://www.garlic.com/~lynn/aepay3.htm#riskm
http://www.garlic.com/~lynn/aepay3.htm#riskaads

somewhat more from the risk manager's perspective ... than either straight
cryptography or computer security.




Lynn,
   Thanks for the references.  I  looked at an online trading system about
a year ago, more from a strategic planning perspective really (this is not
my normal role either).  What I found intriguing was the interaction
between protocols and market structure, particularly in the fixed income
and foreign exchange markets.  This market are far larger than than the
equity markets with individual trades often well into the hundreds of
millions of dollars (your point abouth security commensuarate with the risk
is well taken), but unlike the equity or futures markets they are not open
outcry markets.  The structure of these markets is rather complicated with
a variety of institutions playing several different, fairly well defined
roles.  Depending upon the protocols chosen the resulting electronic
"exchange" canbenefit one or more classes of market participants at the
expense of others.  Hence the plethora of different system trying to
establish themselves, at one point there were more than three dozen
different systems with a vide variety of protocols and security features
depending on whose interests and what information they were trying to
protect.  As you point out the issues go well beyond the problems of a
merchant protecting a customers credit card number when that customer buys
a book online.  Anyway thanks for the references.

Jim Windle
--






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

Re: [FYI] Did Encryption Empower These Terrorists?

[lynn . wheeler]

we were somewhat involved in the implementation of support of commerce
server and hiding account numbers using SSL encryption (probably one of the
most wide-spread use of the technology in the world today).

random refs:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

The problems, of course are 1) account numbers are essentially shared
secrets, 2) SSL only provides for protection for numbers in flight, 3) the
numbers at rest remain a major exploit (as per press stories regarding
copying of account number master files at web servers) ... aka the use of
SSL/ecryption only addressed a small portion of the problem. The web server
account number master file also typicall represents a risk that is
significantly greater than what typical merchant otherwise has at risk ...
making it difficult to support a solution where the level of
security/protection is proportional to the risk

 http://www.garlic.com/~lynn/aepay7.htm#netbank2

note that the X9.59 financial standard for all account-based payments (by
the x9a10 financial standards body) ...  achieves the goal of protecting
both data at rest as well as the data in flight by defining transactions as
being authenticated with digital signatures (and that account numbers used
for x9.59 related transactions can not be used in unauthenticated
transactions). Furhtermore, since account numbers are no longer shared
secrets ... it isn't necessary to "hide" the transaction (with encryption)
in order to protect the account number. There may be other reasons for
using SSL encryption for data in flight ... but with x9.59, the primary
current use of SSL (protecting the account number in flight as part of
electronic commerce) is no longer necessary (and x9.59 is a much more
comprehensive, full spectrum solution ... because it not only addresses the
issue of data "in flight" ... but also problems with the data/numbers "at
rest").

numerous x9.59 references
http://www.garlic.com/~lynn/

some specific x9.59 references
http://www.garlic.com/~lynn/subtopic.html#privacy

some other discussions related to SSL domain name certificates:
http://www.garlic.com/~lynn/subtopic.html#sslcerts

digital commerce trivia question
http://www.garlic.com/~lynn/aadsmore.htm#dctriv




   
   
  "Jim Windle" 
   
<[EMAIL PROTECTED] To:  "Hadmut Danisch"   
   
 ><[EMAIL PROTECTED]>  
   
  Sent by: cc:  
[EMAIL PROTECTED]
owner-cryptography@wasabis Subject:  Re: [FYI] Did 
Encryption 
ystems.comEmpower These Terrorists?
   
   
   
   
   
   09/17/2001 10:11 AM 
   
 Please respond to 
   
jim_windle 
   
   
   
   
   




On Mon, 17 Sep 2001 11:50:13   Hadmut Danisch wrote:
>
>Depends on which kind of logic you apply.
>
>Technical logic: Yes, you're right.
>
>Policital logic: No, you're wrong.
>
>The reason is, that air planes, phones, hotels, cars, etc.
>are used by common people - those who elect politicians -
>and therefore can't be bad by definition. Policital logic:
>What is used by most people who elected me, can't be wrong.
>Which politician would dare to ban hotels?
>
>In contrast to that, cryptography isn't commonly used or
>understood. From a public point of view, cryptography is
>something exotic, used by spys and secret agents, hackers,
>terrorists, who need to keep their business secret. And even
>worse: It's new (at least its civil use with internet). All
>other things exist for decades and have become part of
>normal life. Cryptography doesn't.

As Perry points out in his comment here and as I pointed out in my follow
up posts, crypto is not so exotic as it may first appear.  Not only is it
installed in browsers and used to buy books and whatever else people buy on
the internet while protecting their financial information; it plays and
essentianl role in the financial markets.  While this application may be
largely invisible to most people it is of tremendous importance.  You point
out that crypto is a "martial" technology, to some extend this is true, but
it is increasing used 

(certificate-less) digital signatures can secure ATM card payments on theinternet

[Lynn . Wheeler]

press release ("digital signatures can secure ATM card payments on the
Internet")

http://www.nacha.org/news/news/pressreleases/2001/PR072301/pr072301.htm

results

http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

the report

http://internetcouncil.nacha.org/Projects/ISAP_Results/ISAPresultsDocument-Final-2.PDF

includes the following from the above ...

The "real-world" viability of the proposed ANSI X9.59 standard concept for
electronic payments using public/private key pairs, which is also known as
Account Authority Digital Signature (AADS), was validated by the ISAP Pilot
results. These results demonstrate the feasibility of using PKI without
digital certificates, thereby minimizing infrastructure requirements and
costs for utilizing the ISAP process.



The rfi for the above:

http://www.garlic.com/~lynn/nacharfi.htm

additional  information on x9.59 and AADS

http://www.garlic.com/~lynn

nacha web site

http://www.nacha.org/

nacha organization

Welcome to NACHA

Welcome to the web site of NACHA - The Electronic Payments Association.
Here you will find the latest information on the innovative and dynamic
world of electronic payments.

Electronic payments of all kinds are used frequently by people, companies,
and government agencies as a safe, reliable and convenient way to conduct
business. Direct Deposit is used for payroll, travel and expense
reimbursements, annuities and pensions, dividends, and government payments
such as Social Security and Veterans benefits. Other types of electronic
payments are frequently used for bill payments, retail purchases, Internet
purchases, corporate payments and treasury management, and for the
provision of food stamps and other government cash assistance.

NACHA is a not-for-profit trade association that develops operating rules
and business practices for the Automated Clearing House (ACH) Network and
for other areas of electronic payments.  NACHA activities and initiatives
facilitate the adoption of electronic payments in the areas of Internet
commerce, electronic bill payment and presentment (EBPP), financial
electronic data interchange (EDI), international payments, electronic
checks, electronic benefits transfer (EBT) and student lending. We also
promote the use of electronic payment products and services, such as Direct
Deposit and Direct Payment.

NACHA represents more than 12,000 financial institutions through our
network of regional ACH associations.  We have over 600 members in our
seven industry councils and corporate Affiliate Membership program.

I hope you will find this web site to be a valuable resource.  Please come
again!






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

Re: non-repudiation, was Re: crypto flaw in secure mail standards

[Lynn . Wheeler]

for a fuller discussion of SSL & SET discussion ... set x9a10 mailing list
archives

http://lists.commerce.net/archives/ansi-epay/199905/maillist.html

the above has the postings in reverse cronological order.

but, basically the bottom line is that there are a number of merchant
credit card business process that require the merchant to have the PAN (or
merchant credit card stuff doesn't work).

specific posting (from somebody at visa):

http://lists.commerce.net/archives/ansi-epay/199905/msg9.html







Eric Rescorla <[EMAIL PROTECTED]>@rtfm.com on 07/07/2001 11:54:44 AM

Please respond to EKR <[EMAIL PROTECTED]>

Sent by:  [EMAIL PROTECTED]


To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   Greg Broiles <[EMAIL PROTECTED]>, [EMAIL PROTECTED], James M Galvin
  <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
  [EMAIL PROTECTED]
Subject:  Re: non-repudiation, was Re: crypto flaw in secure mail standards


[EMAIL PROTECTED] writes:
> one of the biggest problems that has led to most of the regulations is
the
> ease that account-number harvesting can occur and then the account number
> used in fraudulent, non-authenticated transactions. The SET-like
protocols
> didn't address this issue.
How so? In at least one mode, SET denied the merchant the PAN.

-Ekr

--
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/






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

Re: non-repudiation, was Re: crypto flaw in secure mail standards

[Lynn . Wheeler]

specific ref.
http://www.garlic.com/~lynn/aepay3.htm#sslset1

in a thread with one of the SET people from visa ... they stated that it
was not designed to prevent a valid merchant from getting the PAN  . in
fact, that there are standard credit card businness process that require
the merchant to have the PAN and that the PAN was alwas returned to a valid
merchant from the payment gateway. I had made the assertion that possibly
the SET option could have been overriden ... which would have inhibited the
ability of the merchant to perform normal credit card business processing
... and was corrected that it was always designed that the PAN be returned
to a valid merchant (and not to inhibit the merchant from being able to
execute standard business processes).


misc. set references from past discussions
http://www.garlic.com/~lynn/aadsm3.htm#kiss6  KISS for PKIX. (Was: RE: ASN.1 vs XML 
(used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/ansiepay.htm#x959ansr  Comments from 2nd LB on DSTU X9.59
http://www.garlic.com/~lynn/ansiepay.htm#theory  Security breach raises questions 
about Internet shopping
http://www.garlic.com/~lynn/aepay3.htm#disputes  Half of Visa's disputes, fraud result 
from I-commerce (more)
http://www.garlic.com/~lynn/aepay3.htm#votec  (my) long winded observations regarding 
X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#sslset1  "SSL & SET Query" ... from usenet group
http://www.garlic.com/~lynn/aepay3.htm#sslset2  "SSL & SET Query" ... from usenet group
http://www.garlic.com/~lynn/aepay4.htm#visaset  Visa Delicately Gives Hook to SET 
Standard
http://www.garlic.com/~lynn/aepay4.htm#visaset2  Visa Delicately Gives Hook to SET 
Standard
http://www.garlic.com/~lynn/aepay4.htm#3dssl  VISA 3D-SSL
http://www.garlic.com/~lynn/aepay6.htm#gaopki4  GAO: Government faces obstacles in PKI 
security adoption
http://www.garlic.com/~lynn/aepay6.htm#ecomich  call for new measures: ICH would be 
glad to help
http://www.garlic.com/~lynn/aadsmore.htm#setjava  javasoft SET - NO!

misc. electronic commerce discusions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3






Eric Rescorla <[EMAIL PROTECTED]>@rtfm.com on 07/07/2001 11:54:44 AM

Please respond to EKR <[EMAIL PROTECTED]>

Sent by:  [EMAIL PROTECTED]


To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   Greg Broiles <[EMAIL PROTECTED]>, [EMAIL PROTECTED], James M Galvin
  <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
  [EMAIL PROTECTED]
Subject:  Re: non-repudiation, was Re: crypto flaw in secure mail standards


[EMAIL PROTECTED] writes:
> one of the biggest problems that has led to most of the regulations is
the
> ease that account-number harvesting can occur and then the account number
> used in fraudulent, non-authenticated transactions. The SET-like
protocols
> didn't address this issue.
How so? In at least one mode, SET denied the merchant the PAN.

-Ekr

--
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/






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

Re: non-repudiation, was Re: crypto flaw in secure mail standards

[Lynn . Wheeler]

true ... but it wasn't standard business practice ... there were all sorts
of options ... the issue was what were the standard business practices
actually followed.

I believe that there is a thread from two years ago on this specific
subject ... where somebody associated with SET explicitly stated that the
standard business practices were not designed to preclude the merchant from
having the PAN.

I can look up the discussion if you are interested.





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

Re: non-repudiation, was Re: crypto flaw in secure mail standards

[Lynn . Wheeler]

... and the x9.59 solution was designed to be applicable to "all"
account-based, electronic payments  not just credit ... but "all".

much of the regs. are specific to credit (because of the ease that
account-number harvesting can lead to fraudulent, non-authenticated
transactions)  ... while the x9.59 approach can not only be used to address
credit but debit as well (one of the other account-based, electronic
payments).

an example is the completed nacha pilot

again refs at

http://www.garlic.com/~lynn/






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

Re: non-repudiation, was Re: crypto flaw in secure mail standards

[Lynn . Wheeler]

one of the biggest problems that has led to most of the regulations is the
ease that account-number harvesting can occur and then the account number
used in fraudulent, non-authenticated transactions. The SET-like protocols
didn't address this issue. However, there is a huge amount of stuff going
on about the need for implementing absolute perfect security at the
millions of merchant sites scattered all over the world ... where there is
an absolute guarentee that at each and every site, harvesting by either
external agents and/or internal agents would absolutely never occur.

by contrast the X9.59 standard (US ANSI financial standards bodies and
pushing forward to international ISO) does address this issue ... where it
allows that the probability of absolte security and each and every web-site
implemented in the world never fails and that there still won't be
fraudulent transactions in association with any kind of (internal or
external) account number havesting (aka charter given the X9A10 working
group in the definition of X9.59 was to preserve the integrity of the
financial infrastructure for all retail, account-based, electronic
transactions. The claim also is that X9.59 definition is also identity
agnostic and can suppurt EU regulations/guidelines that retail transactions
need to not have identity information (i.e. name information embossed on
the plastic and recorded on the magstripe).

misc. ref:

http://www.garlic.com/~lynn/

The X9.59 standard can be obtained from the ANSI publication web site.

http://webstore.ansi.org/ansidocstore/product.asp?sku=DSTU+X9%2E59%2D2000


[EMAIL PROTECTED] on 7/5/2001 wrote:




Implementing non-repudiation as a countermeasure versus spurious "do not
recognize" chargebacks seems to depend on all of the following:

(a) development and widespread adoption of a secure platform for key
storage and Internet use, like the system "whose user interface and
underlying technology is such that the signature is unlikely to be forged .
." described by James Donald above

(b) merchants forcing customers to adopt that platform and SET-like
procedures in order to carry out transactions

(c) changing the Fair Credit Billing Act to make it more difficult or
impossible for consumers to dispute items on their bills.







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

Re: Sender and receiver non-repudiation

[Lynn . Wheeler]

all true

it was part of the original point ... which was that much of the writing
about security in conjunction with digital signatures  all have to do
with the responsibilities of certification authorities.

However, it is possible to have a totally insecure infrastructure with the
best certification authority along with their best policies and practices
... and still have a situation like the "Emperor's new clothes".

It is further possible to have a terrible secure infrastructure with secure
chip-card, secure public/private keys, secure display, secure processes,
along with  trusted digital signatures ... and have absolutely no
certificates.

In lots of cases, you can treat certification authorities and certificates
as totally orthogonal to the issues involved in trusting digital
signatures.

some random refs:
http://www.garlic.com/~lynn/subtopic.html#fraud
http://www.garlic.com/~lynn/subtopic.html#privacy
http://www.garlic.com/~lynn/subtopic.html#sslcerts
http://www.garlic.com/~lynn/subtopic.html#radius




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

Re: Sender and receiver non-repudiation

[Lynn . Wheeler]

there is even simpler "misappropriation" ... that of virus on the machine
... how do you really know what your computer is doing.

with paper signatures  it is somewhat more clear-cut that the person
signing a document ... is actually looking at the document they are
signing. With digital signatures it becomes murkier ... how does somebody
know that what they are looking at is the same thing that the computer is
calculating a digital signature for.

in retail situations, the burdon of proof is typically with the
institutions to disproove any claims of forged signature.

some of the draft digital signature laws (associated with certificates and
certification authorities) started out trying to move that burden of proof
to the consumer (i.e. most of the laws don't so much talk about
"non-repudiation" per se ... they talk about disputes and who has the
burden of proof and the standards for burden of proof). Some of these
somewhat implied that a certificate was sufficient proof ... somewhat
ignoring there could be thousands of foibles that might result in a digital
signature not being what the key owner expected.

business issues typically are associated with amount of risk ... aka how
hard is it to defeat or compromise some system, how hard is it to show
intent, etc.

random refs:
http://www.garlic.com/~lynn/2001g.html#25 Root Certificates
http://www.garlic.com/~lynn/aadsm5.htm#shock  revised Shocking Truth about Digital 
Signatures
http://www.garlic.com/~lynn/aadsm5.htm#shock2  revised Shocking Truth about Digital 
Signatures
http://www.garlic.com/~lynn/aadsm5.htm#ocrp3  Online Certificate Revocation Protocol
http://www.garlic.com/~lynn/aadsmore.htm#schneier  Schneier: Why Digital Signatures 
are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
http://www.garlic.com/~lynn/ansiepay.htm#anxclean  Misc 8583 mapping cleanup
http://www.garlic.com/~lynn/2000f.html#64  Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2000f.html#65  Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2000g.html#34  does CA need the proof of acceptance of key 
binding ?


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

Re: use of digital signatures and PKI

[Lynn . Wheeler]

that has been my assertion for a couple years ... that at least 99.999%
of all cert events that go on in the world today are SSL events for
establishing session keys ...

random ref:
http://www.garlic.com/~lynn/subtopic.html#sslcerts






Don Davis <[EMAIL PROTECTED]>@wasabisystems.com on 05/31/2001 08:07:14 PM

Sent by:  [EMAIL PROTECTED]


To:   [EMAIL PROTECTED]
cc:   Gócza Zoltán <[EMAIL PROTECTED]>
Subject:  Re: use of digital signatures and PKI


i have one potent, anecdotal data point:  a friend of mine is a 3-letter
executive at one of the older/bigger PKI vendors.  he surprised me in a
recent conversation, by mentioning that essentially none of his company's
customers are using PKI for signatures.  actually, he may have said, "
_no-one_ is using PKI for signatures." he says that practically all of the
certs are being used for negotiating symmetric session-keys.

- don davis, boston







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

Re: Lie in X.BlaBla...

[Lynn . Wheeler]

there may be a slightly different issue ... at least, with regard to one of
early projected applications for certificates which was consumer identity
in retail financial transactions. At least EU has talked about making
retail transactions as anonymous as cash ... which sort of rules out using
consumer identity certificates in such an environment (i.e. while consumer
identity certificates in retail transactions wouldn't be fraud ...
requiring them would appear to be in violation of privacy guidelines &
regulations).

a stop-gap solution in europe as been "relying-party-only" certificates
 however, it is trivially shown that appending relying-party-only
certificates to an account-based transaction is redundant and superfulous
(i.e. not illegal just not KISS).

random refs:
http://www.garlic.com/~lynn/2001f.html#31
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/subtopic.html#privacy





Greg Broiles <[EMAIL PROTECTED]>@wasabisystems.com on 06/03/2001 11:00:31
AM

Sent by:  [EMAIL PROTECTED]


To:   [EMAIL PROTECTED], "Enzo Michelangeli" <[EMAIL PROTECTED]>
cc:   <[EMAIL PROTECTED]>
Subject:  Re: Lie in X.BlaBla...


I don't think the new law is necessary - it's basically a retread of
existing fraud and computer misuse statutes - but I don't think it
criminalizes anything that wasn't criminal before. I haven't spent a lot of
time crawling through Washington's criminal code - nor criminal courts,
where the rubber meets the road - so I don't know if the "felony" status
for this is new, or meaningful, or exemplary - it sounds like overkill, to
my ears, but so does much of what comes out of our federal and state
legislatures so I've stopped thinking that's remarkable.






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