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
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]
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
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
).
--
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]
, 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
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
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]
#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
.
--
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]
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
://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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ...
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
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
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.
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 ...
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
Basically there are chargeback rules for card holder present, card present,
as well as ability to read track 12 (on mag. stripe). One of the issues is
that even in card present scenerios with indication that trace 12 could be
read, there are starting to be counterfeits and fraudulent
__
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
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
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.
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
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
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
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
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
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
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
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
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
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
... 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
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
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
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
74 matches
Mail list logo
