X9.59 mailing list
x959 Postings and Posting Index,
next, previous
- home
- The Thread Between Risk Management and Information Security
- AADS & RIsk Management, and Information Security Risk Management (ISRM)
- Half of Visa's disputes, fraud result from I-commerce (more)
- AADS NWI vote
- XML, encryption and certificate comments
- gaping holes in security
- (my) misc. additional comments on X9.59 issues
- [ISN] Card numbers, other details easily available at online stores
- open CADS and closed AADS
- SSL/SET from usenet group
- SSL/SET from usenet group
- AADS related information
- AADS related information ... summary
- X9.59 LUID comment resolution
- Passwords don't work
- Risk Management in AA / draft X9.59
- Risk Management in AA / draft X9.59 (more)
- Risk Management in AA / draft X9.59 (more 2)
- Risk Management in AA / draft X9.59 (more 3)
- 9.59 reference implementation
- Smart Cards with Chips encouraged
- X9.59 discussions at X9A & X9F
The Thread Between Risk Management and Information Security
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx, x9f5@xxxxxxxx
Date: Thu, 21 Jan 1999 04:39:28 -0800
Subject: The Thread Between Risk Management and Information Security
At the two day AADS workshop last week there were nearly 70 participants
including one of the leading technology and financial law firms.
I've attached a perspective by one of the participants on the success
of that workshop. In the early 90s, I was looking at high integrity
business processes and did a definition for business science
... even looking at copyrighting the term. The following takes a
serious look at the integration of information security and risk
management that would be fundamental to business science.
(ref: 2nd wave?)
================================================
The Thread Between Risk Management and Information Security
Last weeks Compaq Workshop was a great success for SITI, First Data,
Compaq & Cybersafe. As so often is the case random events churn out
some interesting results. I realized when we parted company that your
awareness of risk management was not what risk management is in the
traditional context of a risk manager.
This is a recap of our discussion over the weekend to begin to craft a
migratory path to merge information security with risk management. In
its' proper context information security will become a subset of
firmwide risk management, called asset liability management or called
corporate risk management in the corporate world. The practitioners of
this body of science are generally called risk managers, risk czars,
asset liability managers by their peers. They are the corporate
treasurers, CFO's, COO's, CEO's, traders, portfolio managers, quant
jocks, financial analysts, and members of the Board. Some
organizations like Fidelity cause their risk managers and information
security experts to work together. Pretty soon the functional lines
and job definitions will blur. Risk management is the core of an
organizations overall business strategy or strategic plan. Regulators
codify the high integrity value of these necessary plans, actions and
processes.
I would like to begin with an executive context. Remember, if we
elevate information security to the domain of risk management, where
it properly belongs, we will be dealing with the key decision makers
in any corporate or financial entity. From our point of view this is
the optimal point of entry into any client, i.e., The Board or
Executive level. At this level there is also a whole field of Board
and Executive level activities which are defined as the fiduciary
responsibility of these players that supports risk management and will
also warmly receive the essence and importance of information
security. Here is also where the decision making and budgeting issues
for these business solutions will originate. These corporate leaders
are also the ones incented by their organizations to perform this
function.
These best practices are supported/defined/redefined by Regulators
like the OCC, FDIC, SEC, NASD and are the heart of the audit context
of the CPA's that review these practices, as well as, the ilk of the
rating agencies like S&P and Moody's. Expect intrusion detection
information to one day be a public disclosure matter released by the
Rating agencies, much like an airline accident report is public
information. This will become an investor and consumer
requirement. One should further anticipate insurance premiums as a
business relative to corporate information security profiles. These
practices are also the gist of many high end management texts, books,
seminars etc., as they are shaped and re-shaped to find new ways to
enhance and create corporate earnings. Information security risk
management will simply be a new chapter.
For banks the risk management global anchor is called the Basel
Regulations which were set up by the G-7 in the late 80's. Today this
is the high court of global risk management for all serious players
and is chartered by the Heads of Finance ( usually Ministers of
Finance, Secretary of the Treasury, Heads of Federal Banks or Federal
Reserves of a country) of the Group of 30 (G-7 being the core
leadership Group) which are the reps of the top 30 economies. G-7 can
be viewed as analogous to the UN Security Council. FIPS laboratories
are already being told to learn as much as possible about the Basel
Regs and align to the spirit and context of these regs. ANSI
committees are writing information security standards designed to be
sanctioned by the Basel members. The fact that the very first bank
certificate authority, DST was required to be FIPS 140-1 compliant is
an indication that information security and risk management
regulations are intended to be intertwined. Product vendors should pay
particular heed to the portent of this policy. Senior managers and
Board members will discover that high levels of information security
valuation will become part of their overall fiduciary
responsibility. At a baseline minimum expect all financial
intermediary vended products whenever possible to require FIPS 140-1
Level 3 compliance to insure tamper resistant products reach the
consumer end users. The 5C consortium has already missed this
directional arrow and will pay a heavy price to retrofit their pki
architecture so these products, though security enabled, will be
acceptable and price competitive in a regulated environment.
Firmwide risk management includes, interest rate risk, credit risk,
and other lessor subsets. It can be summarized as the task of managing
earnings which is the ultimate responsibility of the Board and the
Execs of an organization. Hence risk management processes are a top
down implementation methodology. This again gives you a good path to
integrate information security into an existing corporate
structure.
The information security kernel is the information security risk
factor as it applies to risk management. A pki is nothing more than a
tool or methodology for generating earnings. For this tool to be used
well it must be harnessed by the existing risk management policies and
procedures of an organization. Information security needs to be
incorporated into the science of risk management so that organizations
can find a handle to develop leadership and competitive skills in
Internet centric business environment. This marriage is happening and
is essential because of the three main capabilities and corollary
attributes of the Internet; 1) communication, 2) brokering, and
finally, 3) mass customization. The Internet is the origin of a new
economic model, never before seen or imagined, on an unprecedented
scale. Organizations will ignore the Internet's impact at their
peril. For the technology to function effectively and efficiently a
common set of business driven ROI practices must evolve to support the
Internet's singularity. Everyone will be touched by this
technology. That is a phenomenal statement about this technology. The
nature of the information security risk profile from the corporate
point of view is that an organization has a dual responsibility of, a)
making money with this technology, i.e., creating ROI, while b)
protecting it's own and its customers information security risk.
First the historical context and Executive Summary:
Risk management is the art of managing earnings. A good description of
the process would be to develop the ability to hindsight as much in
advance, before an event occurs. Essentially senior management has to
address the task of managing earnings in an uncontrollable
environment. Managing a corporate entity is a process of making
decisions based on insufficient data, of inadequate quality, facing an
unknown future, within an uncontrollable environment. How well an
organization accomplishes this feat is the essence and definition of
fiduciary responsibility. Most earning profiles and subsequent results
are based on a correlation between a business strategy and an interest
rate cycle. These cycles in interest rates are uncontrollable, but the
EFFECTIVE structure of the balance sheet --irrespective of the
CONTRACTUAL maturity of the assets and liabilities -- can be managed
to react favorably during each phase of an interest rate cycle.
Earnings are determined by how the balance sheet responds to changes
in interest rates. A constant balance sheet will not produce earnings
or profits during every phase of the cycle ( I can't help but restate
the significance of the AADS strawman chip as a radar blip that is a
traceable evidence trail monitoring the individual transaction level
detail in real time that is necessary to manage the interest rate risk
associated with a company's risk profile or overall balance sheet,
this level of granularity is essential for competent risk management).
Overall it is a dynamic process in a constant state of flux. This
science was created in 1978 when the tools, technology and instruments
for risk management were created. Today, this practice of financial
theory is the navigational sextant of most organizations and a primary
function of a company's Board.
In short, earnings from a liabilty-sensitive balance sheet suffer
during rising rates; earnings from an asset-sensitive balance sheet
suffer during declining rates; a fully "matched" balance sheet may
result in unacceptable low earnings. The Board and Execs are charged
with dealing directly with 1) the causes of poor earnings, 2) fixing
the problem without a reduction in current earnings, 3) creating a
manageable methodology to retain control and flexibility throughout
the interest rate cycles.
Does it matter if interest rates cycle? The difference between small
cycles and large cycles is the difference between reduced and negative
earnings. If the cycle is small, earnings are likely to be reduced by
rising/high rates but most associations would continue to operate. If
the cycle is large and the rising/high rate phase causes operating
losses for more than a brief period few associations will continue
autonomous operations. Technology is a necessary component of creating
the navigational sextant necessary to manage cycles. Imagine extending
what you know today as your vision of end-to-end information security
architectures to integrate with the risk management valuation models.
This presupposes that there will be information security risk
valuation models, which I think you can count on.
These models are measuring risk, on a real-time basis, of the embedded
options of all of the corporate assets and liabilities. These
measurements are based on the greatest granularity an organization can
afford. Once the base calculations are complete the models then
simulate corporate earnings over various possible event horizons
looking for a company's exposure to various interest rate
scenarios. The most prevalent current methodology for doing this type
of analysis is called Option Adjusted Spread (OAS) analysis. This is
in essence a simulation valuation methodology. It's actually like a
pilot learning to fly in a flight simulator. These models simulate
earnings in time across various interest rate scenarios to capture the
impact on an organization. Regulators even allude too and sometimes
require specific rate scenarios. Some regulations actually go as far
as to cause additional net worth capital to be set aside by an
organization based on likely cyclical trends. These regs are
anticipatory in nature. The key question can be summarized as "What is
the value of the organization over X interest rate scenario?"
There is a correlation here with the Chief Security Officer of an
organization as she/he thinks through related issues in a company's
day-to-day business operation as well as any dynamic business process
like e-commerce which is essentially hosted outside the physical
boundaries of a company and as a business process contains complicated
liability and information security risk. Once data used by a
corporation becomes intelligence, it is by definition a risk
management related issue. As long as data can be used to produce
earnings or ROI then it must be recognized for it's risk
factors. These factors traditionally include interest rate risk and
credit risk and with the advent of the Internet they now include
information security risk.
The greatest audience for our work to date are the risk managers doing
OAS analysis. They will get every bit of the AADS, X9.59, ECC
message.Why? Because information security is a) an internal security
risk management process which enhances earnings (if done properly) is
the domain of the risk managers and, b) any dynamic business process,
specifically e-commerce, which "impacts", "grows", "is the source of
earnings", "is an asset growth strategy", falls under the prevail of
risk managers who must model the process in the overall firmwide risk
management process of the corporation. Why? Because failure to do so
could expose an institution to unexceptable levels of risk that could
threaten the survival of an organization. Currently, much like the
early days of risk management our models are primitive. The necessity
for a full scale corporate deployment of a pki to manage information
security risk is only present in corporations that have experienced a
realized loss due to the lack of security. Vendors to date have not
been able to provide a solution set that comprehensively addresses
this firmwide risk. By definition a CA based pki won't work. To date
the AADS ECC model is the only functional model that has a chance of
proving itself successful. The reason is because the model was
designed from the outset to be scalable and to fully address the
firmwide information security risk issues. Corporations are already
exposed to levels of information security risk that Boards, senior
management, and regulators would deem unacceptable and fiscally
irresponsible. They will continue to be exposed as they attempt to
deploy partial CA-pki solutions that only address a portion of the
overall security risk while introducing a host of other risk
factors. Our lack of awareness and sophistication won't prevent
organizational failure. Education and the creation of successful
business methodologies for information security is one of our greatest
challenges and a legacy worth the individual commitment.
These dynamic business activities must be included in the Phase 1, the
risk measurement phase, of the overall process. As we have come to know,
intrusion detection alone can demonstrate significant risk management
exposure which can impact corporate earnings. The entire methodology
from a risk managers point of view can be described in three phases.
Phase 1 is measuring the risk. Information security is clearly a Phase 1
activity when viewed through the lens of a risk manager. Phase 2 is
developing strategies for managing the risk. Phase 3 is managing the
risk. Information security as a complete body of professional practices
is part of firmwide risk management and has a role in each phase.
Historical evolution of risk management as it applies to information
security:
In the late 80's the US financial intermediaries collapsed. We
commonly refer to this as the S&L crisis. It was much more. The
resolution to this crisis was the FIRREA Act of 1989. From a corporate
point of view the question was, "What caused this widespread
dissipation of earnings and broad industry failure?" One of the
answers was discovered in the way we measured risk on a corporate
balance sheet. Essentially, the models were discovered to only be as
good as their data.
Prior to 1989, institutions aggregated their assets and liabilities
into generalized pools. Not much attention was paid to transaction
level detail. The most common product and generalized pools were
Adjustable Rate Mortgages (ARMS). Everyone assumed that an ARM was and
ARM was an ARM. Not so when you consider there are hundreds, perhaps
thousands of different ARM products all booked at various times with
different coupons and varying teaser rates. All behaving in completely
unpredictable, uncorrelated fashion depending on a specific interest
rate scenario. To magnify the problem imagine a situation where the
analysis superimposes instrument credit risk valuations along with
interest rate risk valuations of the ARM as part of the analysis to
fully dimension the transactional and overall institutional risk
profile. Each individual ARM behaves differently in a particular
interest rate scenario relative to its interest rate risk component
and credit risk. A risk manager must also calculate the credit risk
profile of each ARM along a particular interest rate curve for a
complete valuation process to be accurate. Hence each dimension of
risk management is calculated in the risk measurement valuation
process.When institutions began to create financial models measuring
the entire individual transaction level detail of their portfolios
they discovered the gapping error. No one could predict a) the
multitude of embedded options that were going unmeasured across an
organizations entire balance sheet, b) the individual portfolio
behavioral characteristics of these embedded options, c) the
unmeasured aggregate earnings impact of these options across a
multitude of interest rate scenarios. In one example, Citicorp failed
to recognize that a 2% rising rate phase would cause an 80% loss of
core holding company earnings. If the cycle was to occur for an
extended period Citicorp would fail. This discovery caused Citicorp to
get out of the mortgage business in 1989. At the time the company was
the largest player in the mortgage market. Coincidentally, Citicorp's
stock traded at an all time low of $ 6.00/share and needed a private
bailout to continue functioning as an entity. Board and senior execs
have learned to take risk management very seriously. In an Internet
centric business model what is the proper assessment and valuation of
information security risk? How does this component of risk management
integrate with other factors like interest rate risk and credit risk?
In general what is the nature of information security risk? How is it
measured? How does one develop strategies to manage this risk?
Finally, how do I manage this risk?
The pre-transaction level detail era is referred to as the "garbage
in, garbage out" risk management period. In essence the models
reflected what the Board and Execs wanted to hear. The analogy is that
in the current business environment pki's have about the same
credibility as these early risk management models. Their ability to
contribute to the overall risk management strategy of an organization
is nil because they can't be scaled 100 %. Therefore, they have NO
predictive, don't enhance fiduciary responsibility or create any
intrinsic value. Unless they can scale and be used to measure a
complete business strategy they are worse then toys they are
irresponsible. Especially if they cause a perceived level of
information security comfort that can be breached. As the number of
hackers and intrusion attacks become larger and more predatory they
have the potential to cause an associations failure. If a pki can not
address this issue, why build it? If the goal of the pki is not
married to risk management we will create a situation where there is a
false level of security and confidence that these technologies are
bullet-proof. When they are found to be penetrable AND cause
significant earnings loss these activities they can cause
organizational failure. We already have case histories of the Secret
Service, FBI and DEA having entire law enforcement capabilities
corrupted by a single errant hacker. Instances where the objective of
the hacker was self preservation not necessarily tied to destroying an
organization. This is new terrain for corporations and they will have
to craft the answers for themselves. Given the current state of the
art of information security it would behoove organizations to take
this threat much more seriously than they currently do and not look
for answers to be developed for them by law enforcement or industry
Regulators. These organizations are reactive not proactive and more
often than not a company is very likely to find itself thrown into the
information security risk arena for reasons that are usually
unimagined.
The failure rate of the "garbage in, garbage out" strategy was so high
that it correlates to the level and cost of the S&L bailout.
Institutions that knew their data were more likely to survive. The
legacy of the 90's has been the era of intermediaries owning their
data. Some of these projects have been expansive and reached overall
costs in the hundreds of millions of dollars for a single holding
company. These projects originated as competitive processes as
organizations realized the value in their data. A similar awareness is
developing as the early information security adopters realize their
individual earning risk and calculate losses due to poor information
security practices. In the case of SITI reviews of existing pki
designs we have already seen instances where breaches in information
security have caused serious dollars at risk losses, i.e., $ 40M in
oil for one corporation, and $ 200M in internal theft in another. The
press is reporting higher and higher dollar losses for bank related
intrusion cases. This year the NISSC Report announced a five fold
increase in dollars lost due to information security related acts
alone. The current estimates are in the billions of dollars and I
would suggest very low due to the lack of sophistication of our
information security practices and general lack of knowledge and
awareness. This won't go on unnoticed for very much longer by industry
Regulators. As is quite frequently the case, it might take a failure
due to security related issues to cause a policy shift. In the
literature of hackers it is simply amazing how quickly intrusion
activities can bring and organization and its' customers to their
knees.
This cost of this error in the 'garbage in, garbage out era', was not
lost on the Regulators of the day and formed the basis of another
important decision. In the case of financial intermediaries which
include, banks (FDIC), S&L's (FDIC), Wall Street firms (SAIC - not
much here), Insurance companies (state regulated - in general there is
NO back-up for failures), pension funds ( no fund), credit unions
(FDIC), each one of these specific industries is backed by a fund in
the event of a fiscal crisis. Because of the severity of the 1989
banking and S&L failures the funds at the time, FDIC & FSLIC, went
bust (Note: these were the biggest back-up funds, now that they are
recapitalized, which is what WE did, they have been combined into the
FDIC) . Congress had to write legislation to pay for the failure
(FIRREA). For the first time the mismanagement of these institutions,
i.e., the lack of fiduciary responsibility at the Board and Exec
levels responsible for the failure caused the bailout to be funded by
the US taxpayers. In a very real manner every individual wants to make
sure that information security is driven to the highest levels
possible not just to protect their own security and privacy but to
also protect their pocketbook. This should be unquestionably a public
and corporate policy.
To date the last reported dollars I have seen for each one of us to
perform our refunding of the banks and S&L's exceeds 100K per person.
Whether you like it or not, in a rather benign interest rate
environment you will pay over 100K in your lifetime of taxpayer
dollars to pay for this bailout. The dollars are so high that they are
carried as an off balance sheet number so as not to capsize the US
budget or cause attention. At one point they exceeded $ 1
trillion. This is what I mean when I say that ALL of the moneys gained
by individuals in the asset appreciation (real estate) of the 70' &
the 80's went in one pocket and the pay-out of the costs for the S&L
industry came out of the other. The result - a zero, if not negative,
sum game. The horrifying part of all of this was that it happened over
a very benign interest rate cycle. Institutions were toast overnight
because of a short term rate spike. Today prevention and anticipation
are the order of the day and the keys to good regulations.
Regulators know that this structure is a house of cards and if they
don't do their job well they will be the gatekeepers accused of being
asleep at the wheel in the crisis. Regulators love rules that cause
higher levels of net worth to be posted by an institution in an
anticipatory manner. We can create an anticipatory edge for this
technology just by making Regulators and companies aware of the deep,
quick, risk factors related to information security. Intrusion issues
can be as devastating as a huge bond trading loss. They happen quickly
and cut to the core of earnings. As a taxpayer that's exactly the
guidelines you want in regulations. Anticipatory regs go further in
protecting you the taxpayer. When I see regs like those designed for
the Health Care and Insurance industries I view it as a total waste as
far as solving the problems goes. The focus is on the wrong
constituents and masks the fact that if there is wide spread failure
in the Insurance industry who cares if the privacy issues have been
handled well, if the organization fails you can bet you'll get a piece
of the bill.
FIRREA caused a significant shift in US regulatory policy. Today, laws
are written to protect the US taxpayers from any other future bailout
role. The institutions mandate is second to protecting the individual
taxpayer. Risk managers, Boards and Execs must align their business
strategies and policies to this regulatory goal.
FIPS 140-1 can be viewed as a way to protect the individual token
holder, maintaining the high integrity of the overall process and
working within the confines of firmwide risk management. FIRREA was
extended to a global context with the creation of the Basel Regs.
Regulators all over the world can now compare apples to apples when it
comes to analysis of corporate balance sheets. They will need to
extent this risk management practice to include information security
risk.
Japan which was the farthest off when it came to risk management
issues is suffering the most under the burden of compliance. For years
in Japan the official policy has been NOT to record loan losses. Hence
their corporate earnings policy allowed their institutions an unfair
advantage over their global competitors. The Basel Regs changed all of
this when they CAUSED a uniform playing field so that everyone can
measure the counter party risk of any other entity they might choose
to do business with. The Basel regs also captured the policy shift of
the US Regulators in that they recognize that the ultimate source of a
bailout in any country are the taxpayers of that country. Currently,
the Japanese taxpayers are also on the hook for the first time for the
bailout of their country's banking institutions. The Basel Regs are
also driven to protect these very same taxpayers. The upper limits of
this strategy is being tested in countries like the former USSR and
South Africa where the ability of the taxpayers to finance the bailout
is questionable at best. Both of these economic environments are
experiencing extreme interest rate volatility with nominal rates in
excess of 50%. It will be a long time before economic conditions can
support these societies. The true nature of global economies will be
discovered as we collectively solve these indigenous local problems.
Intuitively, these economies might be the best place to deploy pki's
for mass customization of manufacturing processes as a new economic
model. This is a very proactive but welcome solution to a difficult
problem. If pki's can be used in conjunction with telerobotic
technology to simultaneously decentralize the means of production
while simultaneously creating 24 X 7 fully utilized manufacturing
processes there is a possibility we could give Henry Ford's assembly
line production techniques a whole new life while creating individual
and community empowerment. Again, for all of this to be possible an
Internet centric, pki, ROI business process that is scalable and
secure is necessary.
Today, in Japan the taxpayers are for the first time paying for the
financial crisis in that country. This causes an immediate and
significant attitudinal change relative to Regulatory policy. No one
wants to be individually caught up in this twice. Our best arguments
for information security can and will be made along this front,
protect the taxpayers. Once Regulators pick this up in the US or for
that matter any other country the attitude towards information
security will radically shift in the direction we are leading it. The
shift will be powerful and overnight. This is soon to be a fait
accompli. I would without hesitation say to you again that the risk
managers and the Regulators are our true audiences as they are the
ones charged with the mission of protecting the taxpayers while
generating earnings. Their fiduciary responsibilities along this path
are very well defined. Our notions of digital signature technology,
secure transactions and high integrity business processes have a home
here. What we are really creating is the science of information
security risk management. This science is composed of advanced
information security technology and portfolio theory. It will be the
basis for the creation of whole new product markets and new trading
markets. Digital bond trading will be created out of this body of
knowlegde. Without the ECC, AADS, X9.59, pki's, secure chip cards,
hardware accelerators, intrusion detection capabilities, information
security valuation models, secure information technology architectures
( digital distributors), digital rights management systems, etc. you
can't create the cashflows and the contracts to create the bonds. The
next important step is to educate the Regulators. At the end of the
day it would do you well to understand just how little dollars back
the various industry groups and this will give you an idea of how
serious the Regulators take their job. They have very little room for
error in a volatile interest rate environment. The DOI's proper
context vise-a-vise information security lies in how well it protects
the California fund. If the earning at risk due to information
security issues can be shown to be high in this industry then we have
won the implementation battle. Dollars at risk while protecting the
individual customers privacy and security is the key graphic we want
to develop.
The gap today is to map information security to risk management. The
ultimate migratory path needs to show the end-to-end information
security, Internet centric ROI driven business processes while
protecting the ultimate source of any business failures, the
taxpayers. Once the plumbing, policy decisions, risk management, and
taxpayer protection issues are addressed then we can build on the
foundation new processes like digital bond trading or any number of
new pki business models. At some point soon Regulators are going to
cause the whole process to come to a grinding halt until they are sure
that the foundation is laid properly and their constituents are
protected. Wall Street current information security business model
which is devoid of any FIPS 140-1 like context looks to be a likely
battlefield due to customer losses that lead to a fight between
industry participants and Regulators. In the first phase of a bailout
industry participants are asked to pay higher premiums to finance the
failures so all of the members within a specific industry have a
vested interest in insuring a safe and sound level playing field. If
the necessary kernels are not "signed off" and "bought into", then I
suggest that the pace of a standards process will look like warp speed
in comparison. The Regulators are going to want to see demonstrable
confidence in the scalable, secure, efficient, pki information
security methodology. If these Regulators botch it they have to answer
to Congress. None of them wants to do that. Their mission and charter
is clear, a good strategy would be to give them or build them a pki
monitoring capability.
AADS & RIsk Management, and Information Security Risk Management (ISRM)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx, x9f5@xxxxxxxx
Date: Thu, 28 Jan 1999 05:53:14 -0800
Subject: AADS & RIsk Management, and Information Security Risk Management (ISRM)
more work relating Risk Management in the wake of the AADS workshop ...
from one of the participants at the AADS workshop:.
If the efforts to map Information Security Risk Management (ISRM) to
risk management there has been a search for ways to bind ISRM to risk
management and asset liability management. The obvious doorway for real
time ISRM is intrusion detection. The thinking in support of the AADS
ECC pki solution is directed at creating an architecture that can scale
to 100% of the information security needs of an organization. Then
deploy intrusion detection capabilities to craft the necessary and
needed protection to insure the safeness and soundness of financial
intermediaries and business processes. The answer won't be perfect, as
with any valuation model we will have to improve our tools with time.
The immediate goal would be managing on a real time basis the
information security risk of an organization. If this is possible then
it can be demonstrated that information security risk is an important
component of firmwide risk management and will become part of the net
worth regs of a financial institution. The theory is that without a
scalable pki you have a hole in your information security hence in your
firmwide risk management. Where this issue becomes critical is when the
integrity of a critical earnings component of an organization becomes
corrupted due to a breakdown in information security policies,
procedures and practices. In the world of information security one
continuously seeks to avoid what is referred to as single points of
system failure that could cause a whole system to be collapse. When you
think about an information security pki in a financial intermediary
relative to single points that would be targets for systems failure it's
easy to envision key intrusion targets. Two for me are; 1) corrupting
the integrity of the secondary market by altering term contracts via
intrusion and 2) a trading desk environment via intrusion. The second
problem while painful and probable is manageable. It is the first
problem and the lack of a proper methodology to address the problem that
I find challenging. If we cede widespread degradation of the secondary
marketplace it will be difficult to eradicate. Managing the problem and
assuring the business processes will happen. The key question based on
the timeliness of industry actions is at what cost. It would be wise to
address this issue sooner rather than later. Any degradation without a
solution will have a systemic effect on the market reflected in every
pricing structure we know from bond prices to stock prices
I suggest that information security risk management is going to factor
into net worth regs based on the scalability and capability of a pki
model. I wonder what kind of advise a CPA firm would give a financial
client regarding a pki that only managed 40% of the corporate risk of an
institution. Especially, if this information is published as part of an
annual report. I suggest to you that regulatory policies, pool
insurance, rating agencies, servicing companies, even CPA firms are soon
going to recognize this issue. At some point their will be pre-pki asset
pools (that will trade at a discount) and new pools that were
created in an information security risk management environment that
deploys scalable architectures with digital signature technology, secure
transactions and high integrity business processes. I also propose that
intermediaries are going to give away smart cards, chip card and readers
to be able to have an evidentiary trail to asset securitization pools
that are traded in the secondary market. It will be necessary to track
pool degradation due to information security intrusion related events.
The management and inclusion of information security risk as part of
firmwide risk management is going to cause the rewriting of not only our
net worth regs but cause a whole body of policies and procedures to be
codified to support this science. It could turn out that information
security risk becomes the foundation of asset liability management as it
guarantees the integrity of firmwide risk management and business
processes. I am working with some intrusion detection experts. I have as
yet to discover the levels of the problem in a banking, wall street or
trading environment. In the commercial marketplace pki and intrusion
design projects are turning up some alarming details. Especially since
80% of the problems are internal in origin. If any of you have worked
with an such companies I would like to know about it.
The second thread that I am seeking to draw out the elegance of the AADS
ECC model is legal. The fundamental issue is whether legal standards
should be build from either a given technology or from business
practices associated with the use of that strategy. This insight is the
essence of the wisdom of the AADS model created by the Wheelers of First
Data. Prior to the explosion of the Internet e-commerce has been
conducted on a large scale over closed networks, the age of the main
frame. Today we are operating in open networks of distributed
client-server computer systems. Creating advanced technology that maps
into existing commercial practices and business models is what separates
the AADS model from the CA model. At the end of the day we have to find
the best information security model that addresses our need to predict
information security risk, hence, firmwide risk, with the highest degree
of certainty. Because of the AADS ECC model design it accomplishes this
goal. Furthermore, because it is based on standards it can be used by
various e-commerce systems transactors and unlike the CA model has a
very fast rate of adoption cycle. I encourage you to read the work of
Jane Kaufman Winn;
http://www.smu.edu/~jwinn/?attributtionprocedure.htm.
!! NOTE moved to !!
http://www.law.washington.edu/Faculty/Winn/Publications.html
now gone also, but at wayback machine:
https://web.archive.org/web/20060214010557/http://www.law.washington.edu/Faculty/Winn/Publications.html
Especially the UCC
letter and her articles: 1) Couriers Without Luggage: Negotiable
Instruments & Digital Signets and 2) Open Systems, Free Markets and
Regulation of Internet Commerce. The missing piece to complete her
argument is the methodology of information security risk management as
part of the firmwide policies and procedures and risk adjusted net worth
capital regs. At some point soon, there will be a convergence and
alignment of protecting the rights of the consumers and protecting the
rights of the tax payers when a complete methodology for information
security is put in place that protects what initially looks like
disparate tracks. The problem that needs to be solved is for the
leadership of the industry to establish best practices and methodology
for the financial industry to have a context to address information
security risk management. Causing FIPS 140-1 product compliance is a
good example of sound policy. Any regulatory solution should contains
business and regulatory goals that must be addressed by the technology
answer and not cause the opposite result, i.e., technology driving the
business and regulatory processes. Irrespective of any vendors viewpoint
or products we can set high water marks for information security risk
management that will do more to prevent unimagined problems then we are
giving ourselves credit for. It is possible to address the complex
problem of information security risk given the state of existing
technology. Enough of the pieces are there to be a strong deterrent. The
context needs to be established to deploy these technologies. Vendors
could use a constructive context from which to drive their product ques.
This context has to be established, otherwise we get piecemeal,
ineffective technology solutions at the risk of challenging the
financial soundness of the system. No one benefits if this process
extends itself to degradation of the secondary market. At the moment,
the AADS ECC pki technology driven by a business focus, has jumped out
in front of the level of awareness of the business leadership. It is
time to raise the level of industry awareness of information security
risk management so we can maintain the high integrity business practices
that our industry depends on. It would be of great benefit for all of
us; financial institutions, regulators, vendors, to work together to
demonstrate a competent solution set as soon as possible to the
marketplace. This solution set needs to include best practices that
support business processes, regulatory policy and the best advances in
information security technology.
Half of Visa's disputes, fraud result from I-commerce (more)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: "Tom Jones (DRM)" <tomj@xxxxxxxx>
Date: Thu, 1 Apr 1999 08:01:15 -0800
Subject: Re: Half of Visa's disputes, fraud result from I-commerce (more)
seems that this is getting a bit of play on a number of different mailing lists
Please respond to Digital Signature discussion <DIGSIG@xxxxxxxx>
To: DIGSIG@xxxxxxxx
Subject: Re: Half of Visa's disputes, fraud result from I-commerce
At 04:38 PM 3/29/99 -0700, Bob Jueneman wrote:
>Interesting article originally posted to the SET-discuss mailing list....
>
>
>Half of Visa's disputes, fraud result from I-commerce
> By David Legard InfoWorld Electric Posted at 10:24 AM PT, Mar 24, 1999
>
>SINGAPORE -- Although only 2 percent of Visa International's credit card
>business relates to Internet transactions, 50 percent of its disputes and
>discovered frauds are in that area, the company said here Tuesday. It is
>consumers who are responsible for most of the disputes and fraud, not
>merchants, Mark Cullimore, director of emerging technology at Visa
>International Asia-Pacific, said
===================
It seems silly to blame an emergent property of a fundamentally insecure system
on people who had no role in the design of the system. One might even use words
like "emotional" and "irrational".
The VISA number is complete on the card, and on receipts. Staff members of every
vendor who accepts a Visa card in a transaction get all the information that
they need to fraudulently reuse that card number in some other transaction.
Is it negligence on the customer's part that this system was designed in a way
that provides any criminal who can get access to the data from a single
transaction with all the information s/he needs to create many new transactions?
Banks, at least, have a variety of stop-loss measures that they can employ to
detect fraudulent-looking patterns of use of a card number and they can suspend
the card until they check with the customer. (For examples, see my Insecurity of
the Digital Signature paper at www.badsoftware.com).
The digital signature system doesn't provide the customer with these
stop-loss safeguards.
One of my core issues with the current fashion of digital signature
legislation is that, like Visa, we blame users who had no role in the design of
the system and who have no access to security methods that were designed out of
the system, for any compromise of security in the system.
______________________________________________________________________
Cem Kaner, J.D., Ph.D.
P.O. Box 1200, Santa Clara, CA 95052
http://www.kaner.com
http://www.badsoftware.com
Author (with Falk & Nguyen) of TESTING COMPUTER SOFTWARE (2nd Ed, VNR)
Author (with David Pels) of BAD SOFTWARE (Wiley, 1998)
This e-mail communication should not be interpreted as legal advice
or a legal opinion. The transmission of this e-mail communication
does not create an attorney-client relationship between me and you.
Do not act or rely upon law-related information in this communication
without seeking the advice of an attorney. Finally, nothing in this
message should be interpreted as a "digital signature" or "electronic
signature" that can create binding commercial transactions.
AADS NWI vote
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx, x9f5@xxxxxxxx
Date: Sun, 23 May 1999 12:13:51 -0700
Subject: AADS NWI vote
Attached is vote closing for AADS NWI and the comments from the four no votes.
Additional information will be available shortly.
==========================================================================
Dear X9
cc: X9F
cc: X9A
We are pleased to announce that the ballot has closed on NWI, Account Authority
Digital Signature
(AADS) X9/99-LB#12
Date out: 4/06/99
Close date: 5/18/99
Actual close: 5/20/99
18 yes
4 no
0 abst.
40 voting members
Therefore, per Section 14.3.4 a reconsideration ballot will be conducted.
=========================================================================
Date: Tue, 13 Apr 1999 16:55:46 -0400
From: Blake Greenlee <blake.greenlee@xxxxxxxx>
Subject: X9/99-LB-#12
To: dschuber@xxxxxxxx
Dear Darlene:
M. Blake Greenlee Associates, Ltd. votes Negative with reasons on the
subject letter ballot.
Reasons:
Failure to require the use of certificates in conjunction with signatures
may seem like an operational advantage, yet, this approach is not
extensible, and does not support the transparent migration of these types of
transactions to the web.
If the proposal is submitted for a full security review by X9F1, X9F3, X9F4,
X9F5 and X9F6 and is updated to conform to the recommendations of such a
review, then I may reconsider my vote.
M. Blake Greenlee
Principal
M. Blake Greenlee Associates, Ltd.
===================================================================================
From: "Jerry Rainville" <jrainvil@xxxxxxxx>
To: "Darlene Schubert" <dschuber@xxxxxxxx>
Subject: Votes
Date: Wed, 14 Apr 1999 07:44:16 -0400
Darlene,
NSA votes affirmative on X9/99-LB#11
NSA votes negative on X9/99-LB#12
NSA will change its vote on X9/99-LB#12 to an affirmative vote if two
changes are made: 1: The work item be assigned to X9F. (X9A
participation is of course welcome, but to ensure that X9 produce
consistent security guidance, X9F should lead the effort.) 2: The
scope and application for this work item must be more fully and
carefully defined to limit the applicability to those circumstances
that would benefit from this use of certificates.
Jerry Rainville
Director, Center for Standards
National Security Agency
Vice Chairman, ISO TC68/SC2
===============================================================================
Date: Sat, 24 Apr 1999 13:46:09 -0400
From: "Phillip H. Griffin" <asn1@xxxxxxxx>
To: Darlene Schubert <dschuber@xxxxxxxx>
Subject: X9/99-LB#12
Darlene,
Griffin Consulting votes Negative on this NWI. This work is not needed
and similar work on short certificates is already being progressed in
X9F1 as X9.68 and interested parties could participate in that work.
Phil
----
Phillip H. Griffin Griffin Consulting
asn1@xxxxxxxx Secure ASN.1 Design & Implementation
+1-919-828-7114 1625 Glenwood Avenue, Five Points
+1-919-832-7008 [mail] Raleigh, North Carolina 27608 USA
--------------------------------------------------------------
=================================================================================
From: "Stapleton, Jeff" <jstapleton@xxxxxxxx>
To: "Darlene Schubert (E-mail)" <dschuber@xxxxxxxx>
Cc: "Mannal, Robert H" <rmannal@xxxxxxxx>,
"Van Ranst Jr., Alfred F"
<avanranst@xxxxxxxx>
Subject: X9/99-LB#12 NWI AADS
Date: Tue, 20 Apr 1999 00:52:01 -0400
KPMG LLP votes negative on X9/99-LB#12 for the following reasons:
The NWI does not provide any significant business or technical
benefits beyond existing X9 standards or current industry practices
and the draft AADS RFC does not provide any technical detail to
warrant a separate X9 new work item.
There are too many implicit business and technical assumptions and
too many explicit and substantiated claims to warrant a separate X9
new work item.
We are in favor of the AADS model, however the financial industry
would be better served if the RFC was submitted to the X9A10 working
group for the working draft X9.59 Account-Based Secure Payment Object.
Attached are further details.
<<aads-lb#12.doc>>
Jeff Stapleton
KPMG
617-988-6312
jstapleton@xxxxxxxx
(my) long winded observations regarding X9.59 & XML, encryption and certificates
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: (my) long winded observations regarding X9.59 & XML, encryption and certificates
The objective of X9.59 was to define a signed payment object format
that didn't require encryption, preserved integrity of the financial
infrastructure and could be applied to all account-based payments.
Some of the issues:
- the payment object was general enough that it could apply to
all account-based payments and infrastructures
- no encryption was necessary or defined
Because of the large number of different environments that the X9.59
payment object would apply to, various considerations were:
- compact and efficient
- support end-to-end authentication for all financial account-based
transactions and do not separate authentication and authorization
(which has in the past been demonstrated to create fraud
opportunities)
- only define the signed object format and allow different
environments to transport the data elements (specified in the signed
object) in the whatever manner appropriate for that environment,
specifically avoid specifying transmission related characteristics in
order to not limit the applicability of the X9.59 signed payment
object.
- support existing legacy and point-of-sale as well as Internet/WEB
and other types of environments
Some issues raised:
XML signing/authentication format
XML has tended to be a WEB-specific solution as well as currently
dependent on the exact XML document flowing end-to-end. FSTC in
similar e-check work (where the signed object may only exist at the
end-points, and the data elements may take totally different formats
during the transporting phase) found that XML didn't have a single
deterministic representation for data elements. The FSTC solution was
to define SDML (at the time of the X9.59 standards work, and possible
still, has not been released). SDML defines a deterministic
representation for financial data elements and does allow for the
object data elements to take other formats during transmission between
the end-points. The solution chosen for X9.59 data object was to use
ASN.1 encoding of the data elements. The X9.59 data object can be
generated in ASN.1 format at the time of signing, the data elements of
the object can then be decomposed and transmitting in whatever form
determined by the financial transaction, and then the same exact bit
representation can be recreated at the end-point for signature
authentication. This deterministic bit-representation recreation has
not been a feature supported by XML.
Also see "encryption" description of the end-to-end transmission of
the X9.59 digital signature.
Encryption
The X9.59 work on signed data object format was specifically directed
to avoid requiring and/or specifying encryption. Encryption may be a
characteristic of a financial infrastructure transport that moves
X9.59 data elements from one location to another, but is specifically
not part of the X9.59 signed data object format. In fact, typical
transport of the X9.59 data elements can require two-three different
transport mechanisms with some types of intermediate processing at
various locations. Specifying a encryption method for X9.59 when X9.59
is to be applied to a large number of different environments becomes
impractical (besides being beyond the scope).
A trivial example is payment card at point-of-sale (for more
detailed reference see Payment Card reference in the X9.59
appendix):
- X9.59 object is created and signed
- X9.15 message is created (data elements in ASCII alphanumeric)
- X9.59 digital signature is inserted into a X9.15 binary
addenda field
- X9.15 message transmitted by merchant to acquiring processor (MFI)
- Acquiring processor generates ISO8583 message from the X9.15
message (data elements in EBCDIC alphanumeric)
- the X9.15 binary addenda field is copied to an ISO8583
binary addenda field
- ISO8583 message transmitted to the consumer's financial institution
(CFI)
- CFI extracts various ISO8583 data elements, recreates the X9.59 data
object and verifies the X9.59 digital signature
Since there is no X9.59 message, there is no X9.59 message to specify
encryption for. To the extent that such messages (that might be
adopted to carry X9.59 digital signatures) should or should not be
encrypted, should be taken up in the respective standards activities
for those messages. Those messages already exist and currently already
carry the payment transaction.
While it is theoretically possible to build a new payment
infrastructure that used X9.59 data objects as the end-to-end message
format, there are tremendous advantages to limiting the X9.59 standard
to a specification that can be implemented in all (including existing)
account-based payment infrastructures. Encryption is an issue with
respect to the characteristic of those payment infrastructure
operations. Adding a X9.59 digital signature field to those existing
payment messages is hardly a privacy concern (since the binary bits in
a digital signature field hardly represent a privacy issue).
Also, see EU privacy issue reference below and how the addition of
X9.59 can be used to address EU privacy concerns of existing payment
infrastructures (because of X9.59 enabling changes to existing
business process).
Certificates
X9.59 work established that digital signature authentication using
public/private key technology is a basic business process. The use of
certificates for communicating the signer's public key to the
authenticating agency was found to be a subset of that digital
signature authentication business process.
Up until now, certificates have been primarily an Internet and WEB
based solution that could be deployed quickly needing little or no
infrastructure. There is some indications that a major original design
point for certificates were offline email authentication, with the
receiver have little or no inplace resources to authenticate incoming
email. A certificate manufacturing infrastructure (subset of full
certification authority infrastructure) has been pretty much straight
forward to deploy for non-critical operations. The manufactured
certificate, appended to the digital signature provides a method of
communicating the signer's public key to the authenticating agency
(receiver). At issue is that offline email had little or no
authentication infrastructure or authentication material handling
business processes. The financial industry has significant investment
in authentication business processes and authentication material
handling business processes which could benefit from upgrading to
digital signature authentication (without necessitating building
totally independent infrastructures as seen in the offline email
case).
X9.59 was specifically given the scope to define a generic signed
payment object that could apply to all account-based payment
environments. Some number of these environments have significant
difficulty supporting certificate-methodology for communicating the
signer's public key to the authenticating agencies. Furthermore,
large number of cases anticipated for X9.59 deployment, the
authenticating agency for the financial transaction will already have
the signer's public key on file (making the communication of the
signer's public key as part of the transaction redundant and superfluous).
Furthermore, just like X9.59 does not specify the transport format for
the data elements (either with regard to XML or encryption), it also
doesn't specify the transport format for the X9.59 signed payment
object (including no requirement regarding digital certificate as part
of the transaction that moves the data elements between the
end-points). In that sense, X9.59 is agnostic with respect to the
method that the digital signature authenticating agent (i.e. the
consumer's financial institution or CFI) obtains the consumer's public
key.
There is passing reference in the X9.59 document to the possible use
of merchant certificates and consumer certificates as part of
WEB-based shopping experience, but that is outside the scope of the
X9.59 signed payment object definition and doesn't apply to things
like point-of-sale payment transactions. These are considered
"comfort" certificates since they are typically associated with signed
messages intending to establish some sort of identity but aren't
involved in messages that actually effect the transfer of funds. In
part, the Internet shopping experience is being addressed by IETF and
W3 specifications (like the IETF OTP work which includes provisions
for payment protocol "plug-ins" which can make use of X9.59). Even,
the (non-standard) SET specification doesn't flow certificates and
digital signatures through to the consumer's financial institution as
integral to the payment operation.
Generically, certificates are a subset of the digital signature
authentication business process ... describing one method that can be
used for reliably communicating the signer's public key to the
authenticating agency. In order to not limit and confuse the
wide-spread deployment of digital signature authentication for all
financial transactions, it should be kept in mind that a certificate
methodology is only one subset of the authentication business process.
A case in point has been certificate-based financial transactions
targeted specifically for the Internet/WEB environment. The digital
authentication and certificate processing has been done at a Internet
gateway, which then strips off all the digital signature capability
and forwards the transaction (w/o digitial signature) through the
legacy financial infrastructure. This has negated a basic security
tenet, end-to-end authentication, as well as creating fraud
opportunities because different business entities are now performing
authentication and authorization (i.e. the business separation of
authentication and authorization has frequently been shown to lead to
fraud opportunities). In part, this unfortunate circumstance may have
come from viewing certificate-based methodology as a superset of
digital signature authentication business process (rather than a
subset).
From another perspective, the financial and payments infrastructure
have business requirements for authentication. Current business
processes supporting authentication are primarily shared-secret
based (PINs, mother's maiden name, SSN#, etc). shared-secret has the
disadvantage that the shared-secret can both originate as well as
authenticate a transaction (existing business infrastructures need
extra levels of security to prevent divulging the shared-secret).
Upgrading these existing authentication business infrastructures to
public key is straight-forward and eliminates the vulnerability
associated with divulging the authenticating value. Furthermore these
are integrated and robust authentication business processes (as
compared to the certificate design point for offline email which had
no authentication infrastructure). In other words, the existing
financial business processes for managing authentication material can
be leveraged for managing public-key authentication material.
The privacy mandates (initially from the European Union) are also
starting to further complicate certificate use. The traditional
certificate has bound the public key to "identity" attributes (like
name). The European Union objective is to make electronic payment
anonymous (both for WEB/Internet as well as other types like
point-of-sale).
I believe that with the appropriate assurance for a digital signing
chipcard, such a chipcard without any identity information (no name on
the card) can provide a higher level of assurance (even at
point-of-sale) than existing cards containing people names. In that
sense, X9.59 achieves a very high level of personal privacy as a
business process solution (that is not addressed by identity
certificates and/or encryption methods) and would meet the EU
objectives.
A knee-jerk, certificate-based response to the privacy mandates for
financial transactions has been relying-party-only certificates.
These certificates contain only the public key and the account number
(limiting the privacy information exposed at the various processing
stages).
The scenario is:
- key-owner registers their public key with the financial institution
for their account (in theory, leveraging existing business processes in
place for managing authentication material).
- the financial institution creates a replying-party-only (RPO)
digital certificate for the key owner containing only the account
number and public key
- stores the original RPO digital certificate in the account record
and returns a copy of the RPO digital certificate to the key owner
- the key owner creates a financial transaction (including account
number and amount), signs it, and appends the RPO digital certificate
copy and transmits for delivery to the key holder's financial
institution
- the combined transaction arrives at the key holder's financial
institution
- the financial institution extracts the account number from the
financial transaction
- the financial institution uses the account number to read the
account record
- (at least) both the account balance and the original RPO digital
certificate is retrieved (from the account record)
- the public key from the account record is used to verify the
digital signature on the financial transaction
- if valid, the indicated financial transaction is performed.
In such financial transactions, it is easily seen that the key-owner's
copy of the RPO digital certificate is not involved in the payment
transaction and therefore redundant, superfluous, and unnecessary,
i.e.:
- account record must be read to perform the financial transaction
- account record contains the original RPO digital certificate for
the account
- hundreds and thousands of financial transactions will be sent
to the financial institution for processing
- sending a copy of the RPO digital certificate appended to every
financial transaction back to the financial institution where
the transaction will be processed using the original RPO
digital certificate stored in the account record (instead of
the key-holder's copy) is unnecessary
Furthermore, it isn't actually necessary to store the complete
key-owner's RPO digital certificate in the account record since most
of the information (except for the public-key) is redundant (with
existing account record fields) and/or deterministically recreatable.
In any case, since X9.59 only specifies the format and data elements
in the payment object, it is possible for X9.59 to be used in all
account-based payments, all account-based payment methods, and all
account-based payments infrastructures (regardless of whether
certificates are used, practical, and/or necessary for communicating
the signer's public key to the authenticating agency).
gaping holes in security
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: gaping holes in security
recent AP news article on "gaping holes in the security webs of more
than 100 small internet retailers" ... exposing credit card numbes &
personal information
one of the problems with relying on information hiding to provide
itntegrity is that it leads to complexity ... and there can be still
be people that have access to the information. "Hiding" based
infrastructures are in part a problem when trying to generalize to
millions of instances ... in that they tend to be complex and based on
idea that no mistakes will ever be made by anybody.
one of the objectives for X9.59 was to provide integrity w/o having to
hide information. one result is that no encryption is required for
transmitting the information to maintain integrity. the additional
result is no information hiding is required at the intermediate
stages.
a better solution to the gaping holes problem ... is to eliminate it
as a problem ... rather than coming up with even more complex and
exacting processes ... which are even further prone to mistake.
as mentioned early ... a good objective for X9.59 has been KISS
... where elimination of the problem is a better solution than trying
to solve it with ever more complex solutions.
(my) misc. additional comments on X9.59 issues.
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: (my) misc. additional comments on X9.59 issues.
MOID & LUID
The X9.59 payment protocol specifies the hash of order detail
(SHA-1). This is nominally provided by the merchant. The merchant can
create a merchant order in any manner they see fit (which may include
a merchant order ID). The hash of the order detail can be used to tie
the payment to an specific order.
Merchant correlation between the payment and the order is currently
handled by existing merchant mechanisms. The hash of the order detail
establishes a way in the case of a dispute what valid order the
payment was associated with. Also, note that MOID would typically
expected to be merchant unique number and assigned at the time of the
order. Such a requirement could preclude single round trip
implemenation as outlined below.
X9.59 does not specify a length for data items that may be generated
by the ASN.1 object signing procedure.
The example mapping of data elements in the X9.59 signed payment
orject to payment card infrastructure does specify data element
sizes. The purpose of the LUID is to allow the consumer to specify a
number that can be passed with the electronic transaction and
eventually printed on the consumer's payment statement so that the
consumer can organize their payment transactions in much the same way
they organize consumer check register (using sequentially numbered
consumer checks). For the mapping to the payment card infrastructure,
a 64-bit number was chosen, allowing these "virtual" consumer checks
numbers to have a significantly larger numbering range than can be
found in any use today (a 32bit number would be enough to enumerate
4billion payment transactions for the consumer). While the LUID is not
critical to the integrity of the financial infrastructure, any
significant proliferation of electronic payments could contribute to
customer confusion correlating what they have identified as performing
and what might show up on the consumer's statement from their
financial institution. Even the difference between 64-bit number to
carry the LUID versis a 16-bit number raises payload weight concerns
in some existing infrastructures. A 16-bit number (64K) might, in some
cases result in transaction identification truncation (in manner
similar to existing Y2K problems). The result would be that any
consumer statement reconciliation application would need to combined
transaction date with transaction LUID to uniquely identify a
transaction.
Message implementations
The basic signed payment object, in its original scope was to be able
to protect the integrity of the financial infrastructure using only a
digital signature (not requiring encryption and/or information hiding
techniques to achieve this goal).
Furthermore, the protocol exchange was not to preclude a single round
trip implementation (some of the existing payment specifications that
assume a WEB/internet environment require multiple round-trips for a
single payment). This would allow things like shopping from offline
CD-ROM (or settop box), creating a single e-mail including both the
order and the signed payment object ... sent to the merchant. The
merchant after validating the correctness of the order and data
elements in the signed payment object could execute the transaction
and send a single response. In order to support widest possible
applicability for the X9.59 signed payment object, the data elements
needed to be such that the operation could be implemented as a single
round trip (while not precluding multiple round trip message
exchanges). Any merchant supplied data elements in the transaction
needed to be of the relatively general/static variety that could be
distributed in mass-mailings and/or broadcast.
The primary objective of the standard is to establish a signed
paymentobject that can work in all payment environments for all
account-based payment mechanisms.
An optional consumer transaction response object was defined where the
consumer acknowledges receiving the merchants response.
Certificates (X.509, PKI, scalability, misc additional)
X9.59 specifies a digital signed payment object and in order to
maximise he applicability of X9.59 payment object to all payment
infrastructures, there is no mandate on how the X9.59 payment
object (or its individual data elements) is communicated from
the consumer to the consumer's financial institution. It a similar
vain, there is also no specification of how the transaction
authentication material (aka public key) is communicated
between the consumer and the consumer's financial
institution.
It is possible that a brand new, end-to-end payment infrastructure
might be built which communicates a payment message in the X9.59
signed data object format and that this new payment infrastructure
include the appending of a X.509v3 identity digital certificate to a
transmitted X9.59 signed data object. The X9.59 signed data object
specification neither mandates nor precludes such a deployment.
However, it is also feasable for an existing payment infrastructure to
be upgraded from a shared-secret authentication material to public-key
authentication material, with the existing payment messages having the
addenda of the minimum necessary additional data elements so that the
authenticating and authorizing agency for the payment instruction can
recreate the original X9.59 signed data object for digital signature
validation. The largest scaling existing payment authentication
business process is the debit infrastructure which currently manages
shared-secret authentication material. This infrastructure scales to
at least a couple orders of magnitude larger than any existing
Certification Authority PKI (there are possibly some certificate
manufacturing operations within two orders of magnitude of the
existing debit infrastructure, but I know of no fully blown out
Certification Authority PKI that has operations on that order).
The advantage to the existing debit infrastructure to upgrading from
shared-secret authentication material to public-key authentication
material is that shared-secret authentication material can be used to
both originate and authenticate; public key authentication material can
only be used to authenticate a transaction. Such an upgrade has the
advantage of lowering the integrity exposure associated with managing
the authentication material.
As mentioned before, the X9.59 signed payment object specification
neither mandates/precludes the building of a brand-new payment
messaging infrastructure for end-to-end authentication nor
mandates/precludes minimum modifications to existing end-to-end
payment messaging infrastructure.
[ISN] Card numbers, other details easily available at online stores
Refed: **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: [ISN] Card numbers, other details easily available at online stores
misc related information regarding if somebody makes a mistake at a
web server and doesn't appropriately hind all the information from
access ... exposing information for all customers that might happend
to have transacted with that web site.
there was also news note on testimony before House subcommittees on
identity theft problems becoming more common and sophisticated ...
one of the features of x9.59 is eliminating the account number as a
method of attack/exploit ... not requiring encryption and minimizing
need for large, complex, pervasive additional information hiding and
security infrastructures that are frequently prone to errors and
mistakes.
Card numbers, other details easily available at online stores 6.38
a.m. ET (1039 GMT) April 22, 1999
FOOTNOTE: LOS ANGELES (AP) There are gaping holes in the security webs
of more than 100 small Internet retailers, allowing anyone with a
little computer savvy to obtain shoppers' credit card numbers and
other personal information, a technician warned.
open CADS and closed AADS
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: open CADS and closed AADS
some references in the past have contrasted "open" CADS to "closed"
AADS ... seemed to be incorrect semantic characterization ... a more
accurate representation would be to clarify that CADS is designed to
work in offline environment and AADS is designed to work in online
environment (as opposed to open/closed).
Both certificates and accounts bind information and public
keys. Certificates can be packaged with signed messages ... such that
message and the means of authenticating the digital signature is
self-contained and can be performed in offline environments. This is
the presumed original design point for certificates and certificate
infrastructures ... the offline email environment.
In the offline email world is that there wasn't a preexisting
authentication infrastructure and facilities for handling
authentication material. Certificates, Certication Authorities and
authentication binding infrastructure had to be created to fill that
void for the offline email environments.
By comparison, the online financial infrastructure has used account
records for binding information for ages, including binding
authentication information. This has been shown to be an open
infrastructure (in the sense that it is in common use by operations
around the world) and scalable to the hundreds of millions and
billions.
The downside for an independent, authentication-specific business
process is that it isn't sharing its cost infrastructure ... and
therefor the economis of its operation has to be completely covered by
the perceived value of the authentication services that it provides.
By comparison, most existing financial authentication processes are
integrated into the core business process, where authentication isn't
an independently operated and stand-alone (i.e. authentication isn't
being performed solely for the fun of doing authentication ... but
authentication is performed as part of executing some useful business
function). The econmic advantages of an integrated account-based
authentication infrastructure is that the cost and overhead is shared
with the business processes that it is part of.
Fundamentally ... at some level ... both certification authority
operation and account-based infrastructures ... are all account based
with significant expense in operating and managing those accounts. The
integrated account-basd paradigm has the advantage of cost-sharing
extensive account operation expences across multiple business
functions (and doesn't treat authentication as a stand-alone business
operationg where authentication is done purely for the sake of doing
authentication).
Additional characteristics are now started to emerge ... with the
evoluation of an online environment and the desire to have more timely
knowledge of the state of the binding of information found in a
certificates ... there are starting to evolve structures dependent on
online access to current information (either as CRLs or like
OCSP). However, as been demonstrated in the analysis of
relying-party-only certificates, one there is presumption of timely
and online access, the online, timely account information is used and
the offline, stale, static certificate can be ignored (and in many case,
totally eliminated).
This characteristic in some sense gave rise to the characterization of
"comfort" certificates, i.e. using the certificate for authentication
purposes can give some level of comfort .... but for real business
transactions it frequently accepted practice to obtain timely
information (and not sale information represented by a certificate).
In fact, in situations where online and timely status is the
state-of-the-art, and the common accepted business practice ... it may
be difficult to show that use of stale, static informatioin represented by
certificates even meets acceptable business practices (unless
augmented by timely status procedures, and of course, any requirement
for timely status from online account records can obsolete the need
for carrying stale, static information represented by a certificate).
misc. privacy
Refed: **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: misc. privacy
not taken terribly out of context .... the following quote appeared in
the alt.folklore.computers newsgroup today:
If you really want personal freedom, you would be better
off banning credit cards than espousing guns.
as descussed previously X9.59 can provide the strong authentication
necessary to eliminate personal identification requirement from all
payment card financial transactions .... meeting the various emerging
mandates on personal privacy.
along with AADS it meets business requirement for end-to-end
authentication in all environments .... including those supported by
existing legacy networks (where payload weight tolerances is currently
measured in bytes ... creating interesting challenges).
"SSL & SET Query" ... from usenet group
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: RE: "SSL & SET Query" ... from usenet group
tony has pointed out that the dual cryptographic paths in SET from the
consumer (one under the merchant key and one under the acquiring
gateway key) was not to prevent the merchant seeing consumer
information ... but to prevent the merchant seeing the consumer
information until after the payment transaction was done.
this allows that the consumer only has to know the real time status at
the acquiring certificate at the time of the transaction ... but not
to have a similar infrastructure with full blown PKI supporting the
merchant certificate (i.e. the merchant certificate can be a simpler
manufacturing process). Effectively the payment gateway can do either
an explicit or implicit validation of the merchant business process as
part of the payment transaction and delay reflecting the consumer
personal information to the merchant until after that is completed.
This way the consumer only has to check on the up to date status of
the acquiring certificate and not have to check on the up to date
status of the merchant certificate (relying on the acquiring gateway
to validate the merchant status and reflect the consumer private
information back to the merchant ... if appropriate).
Supposedly the inclusion of the "private information" flag in the
merchant certificate was an after thot of the design process ... but
it was never the intent of the original design to preclude consumer
private information from being reflected by the gateway back to the
merchant (after the gateway had peformed whatever implicit/explicit
validation it thot necessary).
"SSL & SET Query" ... from usenet group
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: RE: "SSL & SET Query" ... from usenet group
... the SET alternative could have been ... creating an infrastructure
where the consumer could trust the merchant certificate (at which
point the consumer's awareness of the payment gateway and the payment
gateway certificate could be eliminated).
consumer would only have to
- validate merchant certificate (instead of acquiring certificate)
- transmit all data under the merchant public key
merchant is then solely responsible for awareness of the acquiring
gateway (since the consumer could trust the merchant because the
merchant's certificate could be trusted)
in that sense ... i was incorrect in assuming that the additional
complexity in set was due to a requirement to not inform the merchant
of the consumer's personal information .... the additional complexity
in set and the primary goal achieved by the basic set function is
(only) delaying informing the merchant of the consumer's personal
information until after the acquiring gateway has validated the
merchant (as part of SET being able to avoid requirement for the
deployment of a real certificate-based PKI in support of the merchant
certificate ... although adding the requirement to deploy a real
certificate-based PKI in support of the payment gateway certificate
and requiring the consumer to be aware of the payment gateway at all).
given that explanation ... the SET business requirement for its core
function to not inform the merchant of consumer personal information
until after the merchant was validated ... could also be met with a
SSL infrastructure with a real certificate-based PKI (including
possibly OCSP) in support of merchant certificates (replacing
requirement for there to be consumer awareness of the payment gateway
and a real certificate-based PKI available to the consumer supporting
the payment gateway certificates) ... if the consumer could trust the
merchant up front .... then it could send all the related consumer
private information to the merchant under the protection of the
merchant's public key (not requiring a separate payment gateway public
key to protect the consumer information from the merchant ... until
after the payment gateway had validated the merchant).
Within the X9.59 infrastructure ... X9.59 addresses the end-to-end
authentication of the consumer payment instruction (and is applicable
to all account-based payment infrastructures and methods ...not just
credit or not just internet). That is orthogonal to the SET business
requirement to delay informing the merchant of consumer sensitive
information until after the merchant has been authenticated (with the
slight caveat that the sensitivity of the consumer's X9.59 account
number being drastically reduced since it is no longer a point of
compromise ... no longer being useful w/o X9.59 digital signature).
The X9.59 payment object specification does not in any ordinary way
address the issue of whether the consumer can trust or not trust the
merchant before beginning the transaction (except as stated the
senstivity of the information going to the merchant is drastically
reduced ... and that the X9.59 digital signature should be usable in
lieu of AVS and considered much stronger than AVS for authenticating
consumer transactions i.e. checking to see if the consumer supplied
name/address is the same on record for the account ... address
verification).
This still leaves open the issue of consumer providing the merchant
name/address information for hard goods shipment (or possibly
calculating applicable sales tax?) before the consumer haves some
level of trust in the merchant.
Some approaches
- real certificate-based PKI supporting merchant certificates ... so
consumer has some level of trust before sending the merchant their
name/address
- AADS online data-base akin to OCSP ... but analogous in the real
world to something like the better business bureau
- Signed "shipping object" and shipping accounts ... analogous to
X9.59 for payment accounts ... where shipper picks up package from the
merchant identified with shipping account number ... and the shipper
does the mapping to name/address just prior to deliver (i.e. routing
to final delivery truck done by bar-code related to account number and
only final deliver phase needs actual name/address)
still leaves open taxing authority requirements for at least
consumer's zip code available to the merchant for sales tax
calculations.
it has the advantage of significant simplification compared to SET
... since there no longer needs to be any consumer awareness regarding
a payment gateway aas well as the consumer reliance on the payment
gateway to reflect consumer private information back to the merchant
after validating the merchant.
AADS related information
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: AADS related information
Some misc. issues facets looking at the issue around CADS and AADS
infrastructures
- infrastructure
- payload and certificate compression
- payload and X9.59
- service operation
infrastructure
AADS is straight-forward upgrade to all existing shared-secret
authentication business processes (upgrade from shared-secret to
digital signature using existing business processes).
The CADS infrastructure grew up out of requirement for some sort of
authentication processes for offline email which lacked not only an
authentication infrastructure ... but any infrastructure what so ever
(other than simple address to routing). Part of the problem with
working on the Internet infrastructure from mid-80s until now was the
lack of any origination verification. When I was putting together a
payment gateway for the Internet in the '95 timeframe, as well as
shooting a resource exhaustion problem in summer of '95 for one of the
largest online service providers (nearly a year to the day when it hit
the press in '96 for a similar type of problem) was the lack of
anything to do with origination. Even when the Internet made the
transition from fully-meshed routing to hierarchical routing ... there
was no serious consideration of the ISPs verifying that the from
IP-address on incoming packets corresponded to the subnet that they
were suppose to originate from (similar to boundary packet filters
checking to see that incoming packets from the internet don't have
spoof'ed from IP-address of internal subnets).
For some references see:
https://www.garlic.com/~lynn/internet.htm
The CADS certificates provide two useful functions:
- free-standing authentication infrastructures for operations that
don't have any infrastructure of their own (typical of most offline
email implementations)
- free-standing technology demonstration platforms.
Rather than starting with the premise that CADS is the answer and
searching for the question, it has been useful to look at existing
financial industry authentication business processes and look at what
aspects of technology that is in use by CADS platforms that could be
easily and directly applied. Almost all financial industry
authentication transactions are integrated with business transaction
that reference an account record as part of executing the transaction
(i.e. authentication isn't being performed solely for the sake of
doing authentication but as part of some business operation). The
existing deployed authentication technology is primarily based on some
form of shared-secret (PIN number, mother's maiden name, social
security number, birth date, address, etc, although many of these
shared-secrets are not so secret).
Public key technology provides an opportunity for directly and easily
upgrading all the existing authentication transactions to a more
secure level. Public key technology has the immediate obvious
advantage that the value used for authenticating a transaction is not
the same as the value used for originating a transaction. Recording a
public key in place of an account record secret key has the advantage
that people that view the account record, no longer can originate
fraudulent transactions just by knowing the recorded value.
This potentially has consumer ease of use implications. Current use of
identical shared-secrets across different domains is inhibited because
of the lack of cross-domain liability i.e. protections are in place
for mis-use of a shared-secret within a specific business domain, but
their is less protection when a shared-secret learned in one domain is
then fraudulently used in another domain. There are situations of
people actually listing different "mother's maiden name" in every
domain that they register. Public key registration has the advantage
that just knowing the public key does not allow fraudulent
transactions to be originated.
In that sense, every existing non-face-to-face, authenticated
transaction (electronic, ATM, credit, debit, telephone call center)
could be upgraded to a higher integrity level by converting from
shared-secret paradigm to a public key paradigm. AADS describes a
methodology for this simple and straight forward integrity upgrade
while maintaining the existing business processes.
The business justification for an AADS upgrade to an existing
authentication business process is an inexpensive integrated business
solution with stronger integrity and lower risk.
payload and certificate compression
Fundamentally a certificate binds various attributes to a public key
for authentication purposes. As noted, this provides (nearly) a
free-standing authentication environment for processes that don't
currently don't have their own authentication business processes.
For eons, businesses have used account records to bind attributes,
including the binding of authentication information (typically
shared-secrets).
Sometime in the '96(?) timeframe there was an IETF PKIX thread that
looked at certificate compression, including data compression,
information compression and knowledge compression methodologies. The
objective was to satisfy both transmission overhead (redundant
transmission of identical certificate information appended to every
transaction) as well as the storage of a certificate copy in an
account record at the registration authority (regardless of whether it
was a CADS or AADS registration authority).
The higest level of transmission compression came on transactions with
a central authority. This has since been typified by the financial
institutions in the European Union meeting privacy mandates and other
business requirements with "relying-party" only environment.
If all transactions are being sent to a party for which there already
exists a business relationship and where a corresponding account
record exists, then the highest level of compression is achieved by
just using the account number (since all other information has already
been registered in the account record). Resending any additional
information (other than the account number) is a redundant and
superfluous traansmission of information that has already been
registered in the account record.
Furthermore, for financial infrastructures, the base transaction will
already contain the account number ... therefor appending it after the
digital signature (in addition to having it in the body of the
transaction) is also redundant and superfluous.
So:
- sending more than the account number is redundant and superfluous
for account-based transaction
- sending the account number twice in a message is redundant and
superfluous
- appending anything after the digital signature to an account-based
transaction is redundant and superfluous
payload and X9.59
The opportunity can also be looked at from another aspect. For all
consumer account-based payment transactions that X9.59 covers, the
existing legacy infrastructures measure payloads in terms of bytes and
tens of bytes. The information-based template methodology for
certificate compression is attempting to reduce certificate payloads
from thousands of bytes to hundreds of bytes.
One of the X9.59 mappings has shown a knowledge-based compression
methodology that meets the business requirements of the existing
financial infrastructures and provides end-to-end digital signature
authentication. This recognizes that once the information is
registered in the account record, it is redundant and superfluous to
transmit it again (in this case, the certificate knowledge-based
compression reduces the size of the transmitted certificate on every
transaction to zero bytes ... not hundreds of bytes).
Note that while it is possible to do a AADS mapping for X9.59 consumer
financial account-based payments, consumer account-based payments are
not the only kind of financial transactions that currently have
authentication infrastructures that would benefit from an AADS upgrade
methodology.
service operation
One of the interesting things is how various CADS-based technology
demos back into an AADS-like infrastructure.
There have been some certificate-based technology demonstrations for
consumer payments. They've had the characteristic that
- stripped off digital signature at Internet boundary
- did not provide for end-to-end digital signature authentication
- didn't involve consumer's financial institution in digital
signature technology
- optionally involved shared-secret methodology for end-to-end
authentication (in addition to digital signature authentication)
The interesting characteristics is that the consumer financial
institutions considered that they operate a consumer service business
primarily and that electronic financial transactions are secondary.
While the technology demonstration may not have involved the
consumer's financial institution in digital signature authentication,
in consideration for migration to any sort of production operation,
the consumer service nature of the business required that the
financial institution be able to interact with the consumer with
respect to their digital signature, i.e.
- this was not related to the consumer's financial institution
performing digital signature authentication on electronic
transactions
- this was related to the financial institution believing it is a
consumer service operation and being able to support the consumer
executing a digital signed financial transaction on an account at
the financial institution.
The net was that even if financial institutions didn't implement
technology for verifying digital signed transactions, they still
registered the consumer's public key and provided service support
related to digitally signed transactions (i.e. the call center could
answer qeustions related to digitally signed transactions against the
consumer's account).
What then became obvious, was that once the service operation
registered the consumer's public key in the financial account record
(regardless of the reason that it was registered), it was no possible
to implement AADS-based authenticated transactions. One scenerio has
the financial institution "WEB-enabling" their call center so that
(nearly) every transaction that could be transacted via the call
center could also be transacted via AADS, public key signed, WEB
transaction.
The other aspect of this was that the account registration and
customer support aspects for supporting digital signature transactions
represent the majority of the infrastructure expense. The cost of
infrastructures in support of doing digitally signed transactions is
actually a small percentage what is required to provide account-based
consumer support infrastructure.
With respect to #4, the financial infrastructure eventually realized
for production operation that they had support both a consumer public
key in the account record (the service nature of the business required
it, even if the technology aspect of transaction processing didn't)
and a consumer shared-secret. From the infrastructure cost standpoint,
registration, recording, updating, maintaining, servicing two
different fields with all the associated call center support screens
associated with the field maintenance as well as being able to answer
questions when things went wrong.
The net is that AADS is a methodology that can be used to optimally
upgrade existing authentication business processes while optimally
integrating into existing account-based business process
methodologies.
CADS approaches have been demonstrated to be useful in upgrading
existing environments that lack authentication and account-oriented
operations, especially when no prior business relationship exists.
AADS related information ... summary
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: AADS related information ... summary
- CADS certificate infrastructures are not inexpensive and represent
unnecessary expense when they duplicate existing financial
account-based business processes.
- AADS public key is a perfectly valid method of upgrading any
existing financial secret-key-based authentication business process
... for instance AADS upgrade of the ATM DES infrastructure should be
as valid a consideration as triple-DES.
- European Union has noticed that privacy mandates and other legal
concerns are driving the financial institutions to relying party
infrastructures
- service operations of financial institutions are also driving the
environment towards relying party infrastructures
- account-based, prior business relationship operations are
effectively already relying party infrastructures.
- Concerns about certificate payload weight are driving various
certificate compression schemes ... data compression, information
compression as well as knowledge compression. It is relatively
trivial to show that nearly all digitally signed transactions in a
relying part infrastructures can use knowledge compression to drive
certificate size to zero bytes.
- Providing end-to-end digital signature authentication that
includes use of legacy infrastructures exaserbate the certificate
payload weight issue (where transaction payload weight is measured in
bytes and tens of bytes). Again, digitally signed transactions can be
created that involve minimal increase in transaction payload weight
and knowledge compression for relying party &/or account-based
environments can be used to drive appended certificate size to zero
bytes.
X9.59 LUID comment resolution
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 LUID comment resolution
One of the X9.59 comments was about increaing the size of the LUID
mapping to the payment card infrastructure from 64bits.
The current mapping is 64bits which results in an authorization X9.59
addenda record of 80 bytes.
The LUID is to allow a consumer unique transaction identifier (akin to
the checkbook register providing unique check numbers). The draft had
specified a 64bit number (a 32bit number allows for 4billion numbered
transactions or 4x10**9 ... a 64bit number should be roughtly 10**19
uniquely identified transactions per consumer account).
The current resolution is to increase the LUID mapping in the payment
card world to 128bits or approximately 10**38.
This increases the binary blob addenda record from 80 bytes to 88
bytes. The restriction in the Mastercard bit field is 99 bytes ... so
that leaves 11 byte headroom for new/additional features.
There are some merchant/acquiring interfaces that do transactions in
80byte chunks. A typical authorization might be 50 bytes with an
optional 20 bytes or so if AVS is selected (and padding supplied to
fill the record out to 80bytes).
In the 80byte flavor of the x9.59 addenda record ... there would be an
X9.59 option indicated in the auth, the auth record padded to 80bytes
and the X9.59 addenda record transmited as a 2nd record.
It is still possible to do the 88byte flavor in two records. A basic
contention is that X9.59 transaction should eliminate the necessarity
of (also) doing an AVS transaction. In that case, it would be possible
(for those systems with such implemenations) to use the optional AVS
area for the first segment of the X9.59 binary blob ... carrying the
remainder of the blob in the secondary record. Using this method, such
systems should be able be handle up to possibly 110byte X9.59 binary
blob before being forced to pad out a 3rd record. Using such a
methodology (in those systems that require it), the 88byte binary blob
definition leaves possibly 22byte headroom for new/additional features
that could be added in the future to X9.59 mapping to payment card
infrastructure.
There would be a AVS/X9.59 flag in the basic auth field indicating
whether the optional data contained AVS information or portion of the
X9.59 blob.
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 LUID comment resolution (addenda)
a separate issue with the X9.59 binary blob in implemenations that
span two (80-byte segmented) records involves acquiring systems that
pull the record directly into a (EBCDIC) mainframe host and
automatically perfrom ascii->ebcdic character transaction on the whole
record (by transport services) prior to application processing.
If the first fragment of the X9.59 binary blob occupies an optional
X9.59/AVS space (in most current implementations defined as ascii-127,
alphanumeric) and ascii->EBCDIC translation is being automatically
performed ... then an inverse ebcdic->ascii table will need to be used
by the acquiring application to revert to the original binary blob
value as part of reconstitution and passing to interchange in the
X9.59 addenda bit field.
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 LUID comment resolution (addenda)
.. and finally ... typical mainframe character translation is
typically done "in-place" using the TR instruction that references a
256-byte "mapping" table. Many of the ascii->ebcdic alphanumeric
mapping tables won't map all 256 possibly incoming (ascii) characters
to different, unique values. Since the TR instruction replaces
(destroys) the original information in place ... if a translation
table is used that doesn't provide for mapping uniquely all 256
incoming values ... the translation process won't be reversable (for
the non-unique byte map ... negating the ability to correctly recover
incoming binary data).
... and the reminder/footnote from draft ... since the LUID is part of
the X9.59 signed object, any "lost bits" that might occur in a LUID
truncation as part of transport ... would prevent the original X9.59
signed object for being exactly bit-for-bit recreated at the
end-points and result in failure to validate the digital signature
(i.e. the exact signed object ... bit-for-bit ... must be recreatable
for correct digital signature validation to occur). As a result, code
that is used for X9.59 signed object creation has to be sensitive to
any implementation limitations that are part of a X9.59 mapping to
specific payment environments
Passwords don't work
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Passwords don't work
Password problems account for 20-50% of all calls to help desks,
costing about a million dollars per year for a typical mid-sized
company. About time we start taking the human factors of security
seriously.
Passwords don't work: except for certain circus performers,
nobody can remember a large number of random strings. And yet, how
many security groups include a usability expert? (New York Times
article: access requires free registration.). (August 5)
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Passwords don't work
the reference quote is from an article on human factors related to
security infrastructures ... i believe the article made some
reference/suggestion regarding having human factors expects involved
in designing security infrastructures.
the problem in general is related to shared-secrets ... whether
passwords or symmetrical encryption keys. in distributed environments.
there has been extensive discussion of the AADS chip strawman in
various newsgroups ... part of which i've archived at
https://www.garlic.com/~lynn/x959.html
... and the referenced archived notes typically contain pointers to
full archives of the related mailing lists.
in the card scenerio ... there is pin activiation and biometric
activation ... both of which represent "privacy" information ... but
implemented in such a way that the privacy information (pin or
biometrics) flows between the person and the card that the person
owns. in that sense there is symmetrically unique information that
doesn't have to be distributed across wide area ... but jjust between
the person and the something the person owns.
Risk Management in AA / draft X9.59
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Risk Management in AA / draft X9.59
Date: 08/15/99 03:58:24 PM
With regard to minor changes .... X9.59 mapped to ISO8583 is a minor
change in the transaction processing part of the system. Even looking
at the work item changes going on next year in acquiring and issuing,
... X9.59 support is 5% or smaller than individual work item changes
(and way under 1% of the total work item changes scheduled). This is
remarkable when we believe that X9.59 could be applied to all
transaction environments ... and some of the large work items are only
applicable to small subset of the transaction environments (and/or
involve only small number of transactions).
Also, the nice thing about the X9.59 mapping to ISO8583 infrastructure
(compared to some other electronic payment methods) is that it
actually is mapped inside the current existing business processes
... including software development, testing, verification,
certification and deployment. Any electronic payment protocol not
mapped within the existing issuing & acquiring software methodology
needs to develop its own independent verification, authentication,
certification and deployment process. The X9.59 work item changes to
existing ISO8583 issuing and acquiring implementations is way less
than 1% of work items changes scheduled for this year. Furthermore,
the X9.59 work item changes mapping to ISO8583 issuing and acquiring
implementations are also way less than 1% of what it would cost to
create an independent testing, verification, authentication,
certification, and deployment software process.
The work on X9.59 was done such that it could be used for all consumer
account based payments in all environments (internet, pos, settop
boxes, etc) ... i.e. some characterisitic of the protocol would
practically preclude its use in any of those environments ... and as
been noted elsewhere eliminate significant amount of risk that exists
in the current infrastructure. The question then is with regard to the
X9.59 cost/benefit equation ... i.e. can the X9.59 costs be made low
enuf that for any specific environment, the X9.59 risk reduction (for
that specific environment) outweighs the X9.59 incremental costs.
In the work on the AADS chip strawman (mentioned in previous note)
... it would appear that extraordinary cost reductions are possible
... and with that an expansion in the number of environments where it
would be feasible to apply X9.59.
As for restaurant operation ... within the last two months ... at a
local medium sized restaurant, I had 30 minutes added to my check
processing time because something went wrong with credit-card
electronic authorization and the restaurant needed to be given a card
that they could get a voice authorization on. Is that justification
for saying that all mag-stripe credit cards and all POS swipe
terminals should be eliminated?
Somewhat referred to in the article The Thread between risk
management and Information security ... and various work on doing
parameterised risk management for 50+ lifetime infrastructure (see
various articles and postings archived at
https://www.garlic.com/~lynn/x959.html)
... it is possible to parameterize
financial transactions and establish what level component assurance is
needed for what level of risk ... (and in the credit card area
... establish what level of component assurance results in what level
of merchant discount .... i.e. credit card transactions currently can
have different discount rate depending on whether track 2&3 is
readable).
With regard to business-to-business ... there was some discussion that
X9.59 charter was specifically with regard to consumer/merchant
mapping. There has been work done on mapping an X9.59-like AADS
protocol to business-to-business ... which may or may not result in
new work item in X9.
Risk Management in AA / draft X9.59
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Risk Management in AA / draft X9.59
Date: 08/17/99 05:46:51 PM
actually all X9.59 & AADS is talking about doing is end-to-end per
account authenticatioin using digital signatures ... bank debit cards
already do end-to-end per account authentication ... but with DES
cryptography. Given the appropriate price/performance it is not
unreasonable to consider upgrading DES authentication to digital
signature authentication.
given the appropriate price/performance and human factors .... then it
is not unthinkable to upgrade bank credit to a similar such level as
bank debit (end-to-end per account authenitcation using digital
signatures). i don't see why it would be unthinkable to see bank cards
using AADS authentication .... since (at least) bank debit cards
already are doing "AADES" (i.e. account authority DES) authentication
... and the difference between AADES and AADS is the type & strength
of cryptography. So unless you know some serious flaw in DSS making
it weaker than DES-MAC, there doesn't seem to be any reason for not
considering AADS as a strong authentication upgrade to the current
bank card AADES infrastructure.
given that financial infrastructure seem to be deploying end-to-end
per account authentication into consumer point-of-sale locations (not
just cash dispensing machine) ... it would seem that there has
been advances in availability technology
as to EC privacy direction ... i was talking to somebody at the RSA
conference early this year that had been issued a bank card that only
contained an account number ... and had no name on it at all.
as to the internet &/or MOTO with regard to name/address privacy
... in addition to my discussion of hard good shipments using an AADS
structure (so merchants don't have name/address) that you should be
able to find at
https://www.garlic.com/~lynn/
... there possibly has
been half-dozen or more similar proposals from other
people/organizations.
One could also consider that the current bank credit card
infrastructure has a poor man's DES-MAC in Add Verification System
(AVS). AVS is accocunt specific, no standin and (somewhat) end-to-end
authentication, e.g. an AA-AVS infrastructure. There is even been
some proliferation on the internet of the use of $1 AUTHs with AVS
(where no settlement is actually done) for various types of
authentication purposes. Unless you know some serious flaw in DSS, it
wouldn't seem unreasonable to consider AADS as a strong authentication
upgrade option for the existing bank card AA-AVS infrastructure.
I don't know of anywhere that there is a claim that current stand-in
significantly increases the fraud and risk of the existing credit card
transaction authorization. The issue is that providing end-to-end
strong authentication (along with things like the AADS strawman and
various chip activiation methodologies) would, in fact, eliminate a
lot of the existing types of fraud. At that point, standin might
become the only non-strong authentication, non-end-to-end
authentication for many types of transactions ... and as such,
representing the weakest link, then become a point of attack. This
could even include all point-of-sale environments where debit is also
deployed ... and they would share a common card acceptor device and
other infrastructure characteristics.
The assertion is that end-to-end account authority authentication is
already pervasively used in the bank card infrastructure (both credit
and debit) ... and that AADS would not be introducing new account
authority processes ... but represents a technology upgrade of the
existing account authority authentication mechanisms. Futhermore, the
upgrade to AADS methodology could help address privacy issues related
to name & address information (even in cardholder not present
transactions involving hardgood shipments)
Risk Management in AA / draft X9.59
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Risk Management in AA / draft X9.59
Date: 08/20/99 10:07:33 AM
actually the ECC signing was somewhat the easiest part ... 18 months
ago some of the design point that i put out (somewhat repeated in the
AADS strawman archived at
https://www.garlic.com/~lynn/x959.html)
was
preferably beat (but at minimum met) the geldcard standard for
integrity (i.e. immune to all known smartcard attacks, etc)
same chip be able to deploy no-activiation, pin-activiation and
biometric activation (i.e. chip needed capability to do the biometric
calculation and matching)
same chip be able to deploy contactless or contact
for contactless I used the spec for the sony card supplied by
mitsubishi for transit ... except it had to do the ECC signing within
the same time as the sony card does a symmetric operation in the
transit case; 10cm proximity, 100ms max. elapsed time, trick was the
power envelop for the ECC calculations available from the RF at 10cm
proximity in 100ms. i would guess that the most innovation was both
in ECC calculation innovation, biometric calculation innovation as
well in chip power consumption to meet the proximity power profile
and chip had to be dirt cheap in large quantities.
Risk Management in AA / draft X9.59
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Risk Management in AA / draft X9.59
Date: 08/20/99 05:54:25 PM
at this assurance level ... other threats start to be worried about
... like for any specific chip ... can the risk managers depend on the
associated transactions not coming from a copy-chip. Certified
processes in this area can run $500 per (design, foundary, test,
assembly, delivery)
being able to have certified assurance process (including not dealing
with copy chip) very close to dirt cheap per & that the
risk managers can actually depend on is one of the more interesting
opportunities. while this process is more than neglibile cost compared
to current magstrip card cost ... the certified process can be made
close to neglible increase on the current fully-loaded magstrip
delivery cost (i.e. looking at very high assurance chip that be added
to every magstripe card at as close as possible to magstrip cost
... and very high assurance certification processes that can be
economically added to existing fully loaded magstripe delivery
process).
some amount of this has been discussed before and archived under aads
strawman at
https://www.garlic.com/~lynn/x959.html
X9.59 refeence implementation
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 reference implementation
Date: 09/19/99 01:33:08 PM
The performance numbers are starting to look real good and everything is
on track to being able to do demos at the X9 meeting in a couple weeks.
Issues for a SDK cdrom are:
- handling of crypto library license/API
- handling of ASN.1 library license/API
- permission to include the X9.59 draft standard document on the CDROM.
Smart Cards with Chips encouraged ... fyi
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: Re: Smart Cards with Chips encouraged ... fyi
------- Forwarded by Lynn Wheeler on 09/20/99 09:57 AM -------------------
"Ricki Boyle" on 09/20/99 09:06:09 AM wrote:
To: cryptography@xxxxxxxx
Subject: Re: Smart Cards with Chips encouraged
As someone involved in the US smartcard arena, a little more background is
offered for those interest in this emerging technology......
>I remember Ian, Adam, <someone else> and I talking about the
>card-in-a-floppy thing at CFP '96.
>
>Soulda, woulda, coulda, and all that...
>
>Cheers,
>RAH
>
>
>New Hardware Could Help Web Merchants Cut Fraud
>
>Credit card companies love the Internet, since they pocket a share of most
>e-commerce transactions. But like everything in the world of revolving
>credit, that love has limits. Stolen cards used to make purchases online,
>in particular, cost credit card issuers millions each year -- pushing the
>price of doing business on the Web higher for banks, merchants and,
>ultimately, users.
>
Transaction fraud is important to credit card companies as are the
liability issues. Credit card companies are in legal hot water over
card holders payment of illegal internet activities such as gaming in
states where gaming is not permited. In recent action on a case in
California, a credit card user is sueing over $70,000 debt because the
credit card company allowed them payment access to gaming services.
So even as the major credit card companies and the banks that issue
those cards explore ways to build Internet market share, they are also
looking for creative ways to limit fraud.
Consumer and merchant authentication is also high on the agenda.
The recent launch of the American Express blue card, which comes with an
embedded computer chip, is an example of both efforts. Since the card's
chip can access a user's personal information, it will eliminate the hassle
of typing in that data in every Web purchase -- and, American Express
hopes, encourage people to use its card. At the same time, the chip limits
the fraud by guaranteeing the shopper's identity and offering greater
protection to the buyer's information during the transaction.
The AMEX Blue Card is the start of a flood of bank smartcard initiatives.
The smartcard "chip" opens up alternative business opportunities to banks,
provide card market differentiation and establish a smartcard
infrastructure.
Loyalty, electronic purse, micropayments, authentication, security etc as
well as desktop preferences, browser bookmarks and even software licensing
will migrate to smartcard technology. Smartcards will also appear in
internet appliances in the future as they do today in GSM mobile phones and
satellite TV receivers.
The cards also have very sophisticated crypto capabilities. We are
constantly in process of overseas and domestic export applications
addressing both hardware and software crypto issues.
Those interested can check out smartcard industry sites such as
www.smartcardforum.org or www.smartcardcentral.com as starting points. Both
SUN and MSFT have sites dedicated smartcard OS and Visa has info on bank
related smartcard standards.
Ricki Boyle.
X9.59 discussions at X9A & X9F
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ansi-epay@xxxxxxxx
Subject: X9.59 discussions at X9A & X9F
At the X9F meeting this week there was some discussions about
perceived negative characteristics of the draft X9.59 standard for
signed payment object.
One of the issues was misunderstanding that the various appendix
discussions regarding the mapping of the x9.59 signed object to
various legacy infrastructures as being part of the standard. Several
people pointed out that the appendixes that discuss various ways that
the x9.59 digital signed object draft standard might be used are not
part of the standard. The standard defines a signed payment
object. Standards issues are with respect to the standards definition
of that signed payment object. It was also pointed out in the X9A
meeting that the X9.59 standard was to define elements that were to be
signed using standard techniques.
Separately there were discussions with regard to some of the
appendixes that present how the signed payment object might be mapped
to legacy infrastructures, specifically the AADS definition that
doesn't transmit the certificate along with the data elements in
the infrastructure mapping.
The AADS appendix (and not part of the X9.59 standard) has a
discussion mapping the signed data elements transmitted thru legacy
systems in situations where the registration authority, the
certification authority and the relying party are collapsed into the
same entity. This work relies on previous work having to do with 1)
certificate caching &/or obtaining certificates via independent paths,
2) compressed certificates, 3) certification authority repositories
for certificates, and 4) registration authority verification of signed
objects.
- cached certificates
there has been much standards work going into allowing for not
transmitting the whole certification chain under the assumption that
the relying party may have the certificate(s) cached and/or the
relying party can retrieve the certificates independently. AADS
demonstrates a scenario where it is shown that the relying party
always has all necessary certificates cached and available and/or can
obtain them independently and so it isn't necessary to redundantly
transmit certificates known to be in the possession of the relying
party. For instance, a signed certificate object can be transmitted
without the Certificate Authority's certificate under the assumption
that the relying party may be capable of obtaining the certification
authority's certificate via other methods (and/or already have the
certification authority's certificate cached). The perceived situation
where a signed object meets the objective of always being transmitted
with the corresponding certificate(s) ... is if the signed object is a
self-signed certificate.
- compressed certificates transmission
There is ongoing standards work in the area of certificate compression
where certificate information in abbreviated form. Also when it can be
shown the relying party already always has the necessary field, the
field can be truncated altogether. AADS demonstrates a scenario where
the relying party has a superset of all certificate fields and
therefor the certificate can be truncated to zero bytes. In fact,
stipulating that a digitally signed object and the corresponding
certificate(s) can only be transmitted in their original bit string
representation would preclude using signed objects and certificates in
networks that included hardware compression devices.
- certification authority as relying party
There has been much work done involving efficient certificate
repositories for a certication authority (storing the fields from a
certificate in compressed form i.e. it is not necessary for the
certification authority to store the exact representation of the
certificate if it can reproduce the original bit representation on
demand). In an AADS scenario, where the relying party is also the
certification authority, it is not necessary for the certification
authority to maintain the stored certificate fields in their exact bit
representation.
- registration authority validating a digital signature
An assertion has been made that digital signatures are never
authenticated w/o a certificate. However, much of the registration
authority work defines a process where the user transmits their public
key and signs an object with their private key. The registration
authority verifies the digitally signed object using the transmitted
public key (w/o having a certificate). This process occurs before a
certificate is manufactured. To comply with the assertion, the
registration authority work would have to be changed such that it only
allows registration from entities when they've generated self-signed
certificates which are then sent to the registration authority in
order to obtain a certificate.
AADS asserts that in situations where the relying party is also the
registration authority and the certificate authority it can use:
- certificate caching standards work to not transmit certificates
with the transaction
- certificate compression standards work to compress certificates to
zero bytes
- collapsing registration authority, certification authority and
relying party into a single entity, where the certification authority
is not required to store the original certificate in its exact bit
representation, then a relying party can make use of the stored
certificate representation that was done in its role as a
certification authority.
- collapsing registration authority, certification authority, and
relying party into single entity has precedence where digital signed
objects can be verified using a public key ... which can be obtained
from the repository that is part of its role as registration authority
and certification authority.
Many of the existing certification and certificate standards work
apply to situations where there are different operating entities
involved int the registration authority, certification authority, and
relying party. This standard work promotes interoperability between
independent operating entities.
x959 Postings and Posting Index,
next, previous
- home