Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN .1vs XML (used to be RE: I-D ACTION

From: [email-masked]
Date: Mon, 2 Aug 1999 16:24:23 -0400

Maybe for retail transactions and depending on the level of security
implemented.
Unlikely for corporate banking transactions, since one of the trivial
details would be to know
the secret key assigned to the customer that is needed to authenticate the
payment order.
regards,
eric

To: [email-masked]
Subject: Re: Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN
.1vs XML (used to be RE: I-D ACTION
:draft-ietf-pkix-scvp- 00.txt ))
From: [email-masked]
Date: Mon, 2 Aug 1999 01:00:51 -0700
cc: Russ Housley <[email-masked]>, Ed Gerck <[email-masked]>,
"[email-masked]'" <[email-masked]>

note that while software trojan horse can result in signing of incorrect
data on
payment transactions .... that exploit is significantly smaller than
current
situation where knowing the account number and a trivial number of other
details
allows arbritrary generation of transactions from scratch. no trojans &
non-repudiation is better than trojans & repudiation ... but either one is
a
great deal better than existing situation.

---

From: [email-masked]
Date: Tue, 3 Aug 1999 07:20:35 -0700

with regard to banks dealing with online corporate transactions (typical is cash
management).... was difficult going from dumb terminals to online PCs ... even
with passwords ... a big concern was that corporate people would program
password into automatic scripting software as well as how lax they were in what
kind of software introduced onto the machine. basically there was very wide
variation across companies in how they observed information security policy with
regard to PCs used for doing online corporate banking transactions. the advent
of the internet is even more challenging .... as part of offering service and
reducing the cost of doing business ... corporate online banking software
package can have nearly 50 different versions to correspond to different kinds
of PCs, different kinds of PC operating system, different releases of PC
operating systems, as well as different modems. Going to internet SSL/VPN gets
the bank out of the sofware product business ... as well as all the software
product customer calls. The downsides is the level of information security is
typically even worse for PCs used for internet connections ... than what was
observed for previous generation of online-banking PCs. With broad range of
corporations using online banking software ... it was/is difficult mandating
appropriate level of information security for the machines involved. range of
companies from small operations with a dozen employees or less up thru very
large corporations with hundreds of thousands of employess ... required that
banks be somewhat flexable &/or look the other way.

trivial problem with (corporate) banking passwords/secret keys ... is that there
tends to be one per corporation ... with multiple corporate officers knowing the
value. in court cases ... one of legal non-repudiation issues is to show that
only a specific person could have executed a fradulant transaction.

the common exploit for passwords (& secret keys) is various kinds of social
engineering ... only the very largest corporations may have stringent training
with strong auditing procedures and unannounced penetrations/attacks ... that
they will be sure that their people are immune.  going to hardware token digital
signging (with or w/o certificates) cuts the possibly exploit to trojan horse
infections that display one thing on the screen ... but present the token
something else for signing.  for court cases ... would need hardware token per
person (non-shared) as well as demonstrable information security showing PC was
free of trojan horse software. observation is there is broad range of compliance
of information assurance among corporations using online banking for things like
cash management (including sweaping various amounts between different accounts
and/or even different banks). if lots of corporations were telling a bank that
that they were going to another bank to get "internet-based" online cash
management ... they would tend to try and provide the service ... regardless of
what their security people thot about the current state & vulnerbilities of
internet based services.

also there was recent note that (german) court held bank liable in fraud case
based (in part) that technology relied on DES and DES is not secure enuf
anymore.

[email-masked] on 08/02/99 01:24:23 PM

To:   Lynn Wheeler/CA/FDMS/FDC@FDC

Maybe for retail transactions and depending on the level of security
implemented.Unlikely for corporate banking transactions, since one of the
trivial details would be to know the secret key assigned to the customer that is
needed to authenticate the payment order

regards,
eric

note that while software trojan horse can result in signing of incorrect data on
payment transactions .... that exploit is significantly smaller than current
situation where knowing the account number and a trivial number of other details
allows arbritrary generation of transactions from scratch. no trojans &
non-repudiation is better than trojans & repudiation ... but either one is a
great deal better than existing situation.

---

From: [email-masked]
Date: Tue, 3 Aug 1999 07:24:15 -0700

oh yes ... i don't know about the availability to non-members ... but example of
some of the discussions on business banking:

http://www.global-concepts.com./forums/if_members/April_98.html

http://www.global-concepts.com./forums/if_members/if_presentations.html

---

From: [email-masked]
Date: Tue, 3 Aug 1999 07:43:27 -0700

... oops and sorry for going on ... but question of whether bank is liable tends
to be different than whether or not a specific person can be convicted in case
of fraud. bank
can establish all the information assurance procedures that a corporation has to
follow ...and try and get off the hook for liability in case of (online)
fraudalent transaction. that is somewhat seperate from whether a specific
(corporate insider or external) can be convicted of executing the fraudulant
transaction.

---

From: [email-masked]
Date: Tue, 3 Aug 1999 11:22:28 -0400

Yes. And banks face different liability requirements in different
jurisdictions and customer types (retail/consumer, wholesale/corporate0.
And, in most cases, banks can get the money back if they detect the fraud
quickly enough.
eric

[email-masked] on 08/03/99 10:43:27 AM

To:   Eric Guerrino
cc:   "Russ Housley" <[email-masked]>, "Ed Gerck" <[email-masked]>,
      "[email-masked]'" <[email-masked]>
Subject:  Re: Common misconceptions,      was Re: KISS for PKIX. (Was: RE:
      ASN .1vs XML (used to be RE:  I-D ACTION

... oops and sorry for going on ... but question of whether bank is liable
tends
to be different than whether or not a specific person can be convicted in
case
of fraud. bank
can establish all the information assurance procedures that a corporation
has to
follow ...and try and get off the hook for liability in case of (online)
fraudalent transaction. that is somewhat seperate from whether a specific
(corporate insider or external) can be convicted of executing the
fraudulant
transaction.

---

From: [email-masked]
Date: Tue, 3 Aug 1999 11:17:37 -0400

I was not implying that existing banking software provides for
non-repudiation. On the contrary, the fact that banks are using secret keys
for message authentication precludes this. And, as you noted, many banks
provide only one authentication key to be shared by all users at a customer
site. I created a PC-based cash management system in the early 80's, which
is still in use today but will soon be replaced by an internet-based
offering. The PC software requires one userid/password to authenticate to
the PC and a separate ID/password to authenticate a transmission session. A
DES-like algorithm is used to authenticate the messages utilizing a 56-bit
key that can not be scripted by the user (clipboard operations are not
supported for the field).

In moving the product to an internet-based client, one consideration was
use of client certificates versus user ID and dynamic passwords (hardware
tokens) for authentication. Our conclusion was client certificates required
too much administration and maintenance overhead, in the long-term, while
providing few incremental benefits The ability for certificates to support
nonrepudiation was examined in detail because it was the one major
potential benefit we could not support with alternatives, which are all
based on the secret key concept. Unfortunately, we concluded that current
software implementations of certificate technology did not provide a level
of security adequate to support nonrepudiation claims.

I agree password systems are inherently weak. In moving to an internet
client, the known weaknesses of password systems led us to the hardware
token decision. Each user is issued a separate token and the customer is
cautioned to discourage sharing (which would imply a sharing or IDs and
passwords as well which is a violation of our security policy).
Unfortunately, we admit even this does not provide assurance that is strong
enough to serve as a foundation for nonrepudiation, but it is significantly
easier to manage.

regards,
eric

---

From: [email-masked]
Date: Tue, 3 Aug 1999 16:44:44 -0700

basically what AADS has been looking at is an EC/DSS hardware token at the
highest currently available hardware assurance level ... as close in cost to
current magstripe debit cards as possible ... with the public key registered
associated with the account/userid in place of password ... and digital
signature authentication of messages ... in lieu of password compare.

---

From: [email-masked]
Date: Tue, 3 Aug 1999 16:54:47 -0700

we believe that we can deploy a common digital signature authentication
technology for all transactions (including login transactions) that supports
software public key as well as various hardware token public key ... where the
choice becomes one of the parameterized risk management issues.