ng 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
--
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]
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
-
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
---
02j.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/
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
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/~
e 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
repl
).
--
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]
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/~l
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]
;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://w
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 Cryp
sted
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
discussing these
problems.
Regards,
Birger Tödtmann
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to
[EMAIL PROTECTED]
--
Anne &a
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],
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/
---
s 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/
-
Th
ites?
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 [EM
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/200
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 th
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 t
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 resis
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 prel
"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 .
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 ch
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 d
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
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 som
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 wi
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
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 biome
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 record
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 th
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 fraudule
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 prob
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#a
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 ba
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) t
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 ...
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
n
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
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.
"Fr
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"
opera
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 ...
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 com
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.c
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
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 be
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 interne
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
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
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 s
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
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 bef
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 var
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 nam
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
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-
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 dig
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
merchan
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 car
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
.
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
somethin
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
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.
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 p
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)
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 transaction
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-authenticate
__
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
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.
--
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
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 differe
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 o
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 i
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 r
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 ten
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
mi
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
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 securi
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/aad
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
4: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-re
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 P
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 stat
... 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
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
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 ce
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 si
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 0
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
c
96 matches
Mail list logo
