AADS discussion from the dcsb mailing list
20030101
- 20021231
- 20020630
- 20010311
- 20011230
- 20011110
- 20011005
- 20011002
- 20010615
- 20001215
- 20001118
- 990730
- 990509
- Collected postings: 2003- ,
2001-2002,
1993-2000
- home
Attached is a series of postings (and responses) that I
made to DCSB mailing list on the subject of Account Authority
Digital Signature model.
- AADS & X9.59 Overview
- Followup Postings
- Variations on model
- AADS/CADS Complexity issues
- Parsimonious implementation
- AADS & X9.59 performance and algorithm key sizes
- More Performance; Paradigm shift and liability
- Comfort certificates, Identity and Privacy
- Certificates create fraud potential
- AADS, X9.59, security, flaws, privacy
- authentication/authorization flaws/liability
- Law vs Economics
- Statistical Attack Against Virtual Banks (fwd)
X9 is working on x9.59 electronic payments in the x9a10 working group.
In support of x9.59, I've been working an account authority digital
signature (AADS) model.
In the financial industry it combines the characteristic of
a digital version of the signature card, the "mother's maiden
name" field and the next generation replacement for PINs.
The registration of the public key in the account record allows the a
digital signature to verified electronically (analogous to the way a
written signature is verified against the signature card). A
registered public key allows a digitally signed transaction to be
authenticated in much the same way a telephone transaction would use
knowledge of "mother's maiden name".
The public/private key methodology is also the next generation
replacement for PINs. One of the current problems is that PINs are
shared-secrets and PIN recording at the financial institution requires
special handling. Public keys have the advantage that they can only be
used for authenticating a transaction (but not for originating a
transaction).
I've also been working on both a payment and a security taxonomy
and glossary; they are at:
https://www.garlic.com/~lynn/payment.htm
https://www.garlic.com/~lynn/secure.htm
they are similar ... but different to the stuff that I've done with the
ietf rfcs (in part what goes into section 6.10 in std1):
https://www.garlic.com/~lynn/rfcietf.htm
Three digital signature models are described; the original "offline"
model (Certification Authority Digital Signatures; CADS) and two newer
"online" models (Account Authority Digital Signatures; AADS). It is
expected that the two "online" models become the prevailing modes of
operation for online financially-related and/or electronic commerce
transactions.
Digital Signature Model 1:
The traditional PKI infrastructure talks about issuing certificates
that are signed by a certification authority which attest to the:
validity of the public key
preferably checking validity of the private key
possibly some identity information of the entity
that the certificate is issued to.
The associated PKI-use model has an entity "digitally signing" a
document with their private key and "pushing"
the transaction/document
the digital signature
a copy of their digital certificate
to another party. The receiving party presumably will validate the
authenticity of the digital-signature and the originator's public key
via the contents of the associated digital certificate. Originally
the contents of the digital certificate was assumed to be sufficient
such that digital signature validation could be performed without any
additional electronic transmissions. As the methodology matured, it
became apparent that more and more complex verification mechanisms
were needed, if nothing else various status could have changed between
the time that the certificate was originally manufactured and the
current moment. Certificate revocation lists (CRLs) were one such
development in an attempt to partially address the issue of current
real-time certificate status in the offline verification model.
Digital Signature Model 2 (or account-based PKI):
This is a proposed implementation for the X9.59 framework. An
account-holder registers their public-key (and verification of their
private-key use) with the account authority. In a transaction the
account-holder digitally signs a transaction and pushes the
transaction, the digital signature, and the account number.
Eventually the transaction arrives at the account authority and the
digital signature is verified using the public key registered in the
account record. The account authority maintains the status of the
holder's public key as part of the overall account management
process. The transaction therefore requires neither a certificate nor
some complex status methodology (like CRLs) since the account
authority maintains current validity status as part of account
management.
This is effectively the X9.59 check and credit-card models where the
receiving entity/business forwards the payment instruction to the
account issuing institution. The payer's digital signature is
forwarded by the receiving business to the issuing institution; the
issuing institution authenticates the digital signature using the
registered public-key in the account record. No signed certificate
attesting to the validity of the public key is required since the
public-key is on file in the account record.
An account-authority performs the majority of the same functions
performed by a certification authority, but the processing costs are
absorbed by the standard business process ... not by charging for the
issuing of a certificate. It is possible that an account-authority
might also wish to become a certification authority since it potentially
could be undertaken at less then 5% additional business costs.
Digital Signature Model 3 (positive authentication):
This is actually a slight variation on #2, although it bears some
superficial resemblance to #1. The initial designs for positive
authentication PKI, used the credit-card authorization model to
replace CRLs. However they kept the rest of the infrastructure; the
originator's certificate was still pushed around with the transaction.
The receiver validated the CA's signature on the certificate, then
sent off a certificate status request and validated the CA's signature
a second time on the status response (and then validated the original
digital signature).
Model #3 looks very much like model #2 in that the originator's
certificate is not pushed around with the transaction. However, rather
than sending the digital signature in the authorization request, just
the certificate identifier (account number) is sent to the CA. The CA
signs a status response that includes information regarding the
real-time validity of the account along with a copy of the account's
public key. In effect the real time status response becomes a
mini-certificate. The entity that will act on the transaction now only
has to verify the CA's signature on the status response (i.e.
mini-certificate, it doesn't also have to verify the CA's signature on
a certificate manufactured at some point in the past). It then uses
the public-key returned in the status response to validate the
originator's digital signature.
Superficially this resembles digital certificate model #1 but the
actual operation is much more like model #2. Including the account's
public-key in the real-time status response creates, in effect, a
mini-certificate. It also eliminates a redundant and superfluous
validation of the CA's digital signature (on both the manufactured
digital certificate and the real-time status responses).
The biggest operational difference between #2 and #3 is that the
account authority verifies the originator's digital signature in #2
and in #3 it just returns the value of the account's public key for
the requester to validate a digital signature. If the requester can
send the document or even the secure hash of the document to the
account authority along with a copy of the digital signature, then the
account authority can verify the digital signature. If not, the
request just identifies the account and the mini-certificate is
returned allowing the requester to validate the digital signature.
The positive authentication model presents a number of revenue
opportunities for the CA to charge for various levels of detail
returned in real-time status responses (and/or approval levels
associated with the transaction).
Conclusion
Digital signature model #1 was originally developed to allow "offline"
verification of a digital signature. A manufactured certificate was
pushed along with the signed document and the digital signature could
be verified using just the contents of the certificate that was passed
along with the document.
Offline signature verification using a certificate manufactured
several months in the past (and by implication relying on status that
was several months stale) turned out to be inadequate for various
kinds of transactions. This has led to the definition of more
complicated processes in the certificate-push model in an attempt to
provide more timely status and verification.
There has also been the implicit assumption that only the certificate
authority is performing registration services for digital signature
processes. As the concept of digital signatures have become more
acceptable, it has also becoming apparent that existing business
processes (already performing account registration functions) can be
simply extended to add public-key registration.
Revisiting the PKI basic architecture, it became apparent that there
were several optimizations possible if it was recognized there were
significant numbers of online PKI operations (compared to earlier
models that started out assuming offline PKI and later tried to graft
online features afterwards).
The offline validation and certificate push model is still valid for
some types of transactions and shouldn't be precluded. However, real
online validation (models #2 and #3) can eliminate some number of
superfluous operations.
It should be noted that the "offline" validation is different than the
"offline" purchasing referred to in X9.59. X9.59 assumes that the
purchaser/payer can be offline and transmits an order and payment
instructions via methods like email (not requiring real-time, online
interaction with the business). In the validation process, there is
an issue whether the business is also offline at the point that it
approves the transaction. If the business is offline, then it needs a
payer's certificate to validate (and authorize) the payer's
transaction. If the business is online, then either model #2 or model
#3 is used (and it is not necessary for the consumer to push the
certificate with the transaction). Furthermore, in the case of model
#2, either the business can perform its own PKI registration function
and/or it can rely on a financial account infrastructure to have
implemented a PKI registration function.
It is expected that digital signature models #2 and #3 become the
prevalent modes of operation for at least financial transactions.
Denial of service attack addenda
There is a hypothetical case (that can be made for certificate pushing
in the online world) which is associated with anonymous denial of
service attacks. The existing Internet infrastructure provides
significant opportunities for electronic terrorists to anonymously
(and/or under assumed identity) launch denial of service attacks
(flooding a web site with enormous number of bogus requests). These
are undertaken with the assumption that it is nearly impossible to
trace the source of the attack.
One of the techniques for dealing with denial of service attacks is to
recognize and eliminate bogus requests as soon as possible. If a
certificate is pushed with a request then some preliminary screening
of requests can be performed during initial processing and possibly
eliminate some number of bogus transactions.
The downside is that public key operations are extremely expensive;
preliminary screening of a request using the certificate (and still
doing the online validation later) could be more expensive than
allowing bogus transactions through and recognizing them via the
standard mechanism.
Most of these are simple band-aid solutions. The real problem is that
existing Internet backbone operation makes it simple to impersonate a
network address. As a result it is usually very difficult to trace
back to the originator of an electronic attack.
variations on your account-authority model (small clarification)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: variations on your account-authority model (small clarification)
I don't see this as two different methods of public key ... the basic
principles of public key are the same in both AADS and CADS models.
One way of viewing the scenerio is to decide whether the inclusion of
a certificate (especially from a 3rd party) increases the trust among
the parties of the transaction.
In the offline and/or NPR (no prior reliationship) scenerio ... a 3rd
party participation and the use of a certificate can increase the
trust in the operation.
However, I don't really see where a 3rd party certificate improves the
trust in a transaction between an account-holder and their financial
institution. The addition of a public-key registration field to an
account-record provides both a general solution and doesn't involve
the introduction of unnecessary participation by parties not involved
in the business operation.
The verification of the digital signature ... should be the same
whether or not the public key is obtained from a certificate or an
account record. The integrity of the network operations should be the
same whether or not a certificate flows with the operation.
For account-based transaction ... intergrating a public key field into
the account-record shouldn't adversely affect the integrity of the
account record or the execution of the transaction.
Where complexity really comes into play are all the business processes
and trust relationships that are related to an account. Looking at the
operation of an account-based service ... the parts of the business
processes that account for the registration and issuing the account
may represent less than five percent of the total operation.
Translating that into an hypothetical Certification Authority service;
the processes currently proscribed for registering a public key and
the manufactur and distribution of a certificate ... would only
account for five percent of the processes of a full-blown service
operation.
It would be a foolish business strategy to introduce into a complex
account-based business operation with a strong trust basis the risk
and liability of a 3rd party certificate that can't increase the level
of trust and/or security (and actually introduces new systemic risks).
The benefits of 3rd party certificates in a NPR (no prior
relationship) &/or non-trust environment can outweigth the costs of
new systemic risks. However, it would be poor business strategy to
force the use of certificates where they add no value and increase the
systemic risks.
I don't view there being a hundred-odd AADS scenerios any more than
CADS, which has been relatively successful in normalizing a large
number of different NPR, offline &/or non-trust operations. I do
belive that in terms of value and number of uses, the AADS operations
will strongly dominate the use of public key ... far outstripping the
CADS, NPR, offline &/or non-trust uses.
For help on using this list (especially unsubscribing), send a message to
"dcsb-request@xxxxxxxx" with one line of text: "help".
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: variations on your account-authority model (small clarification)
in AADS, a public key is registered with the account-authority
... effectively the digital equivalent of the signature card;
technically it is analogous to the way a public key is registered with
a CADS ... but no certificate need be issued ... since it is never
necessary to push a certificate along with a payment instruction; the
issuing bank is able to validate a signed payment instruction with the
public key registered for the account (the purpose of the certificate
supposedly is to allow a digital signature to be validated w/o resort
to any additional mechanism ... especially in the NPR/no-prior
relationship scenerio).
in the financial scenerio ... seperating the authentication of the
payment instruction (from the approval/execution) via the certificate
(possibly stale &/or dependent on large number of complex network
operations) creates (at least) both liability as well as a systemic
risk problem ... which are unecessary.
In CADS, a pushed certificate (accompanying a transaction), supposedly
relies on the certification authority signing of the certificate
(indicating a valid public key for the transaction). The financial
authority, executing the transaction, supposedly would use the public
key in the certificate (after verifying the certificate digital
signature of the certification authority) to validate the signature on
the transaction.
CADS is a reasonable model for the offline & NPR operations
... possibly providing an improved sense of security for two otherwise
anonymous (to each other) parties (and hopefully risk). A trusted 3rd
party certification authority can improve the integrity of an
otherwise somewhat random event.
In the financial account transaction operation ... where there is
already a significant relationship ... inserting dependencies on a 3rd
party into the process, increases the risk (rather than decreasing
risk ... in contrast to the NPR scenerio)
The word/lawyer example turns out to be bit of a red herring ... if
really comparing apples-to-apples ... it would be not whether or not
"legal options" were available for word documents ... but instead the
legal option not only had to exist ... but a legal attachment (aka
certificate) had to sent with every document (whether it was needed or
not).
For help on using this list (especially unsubscribing), send a message to
"dcsb-request@xxxxxxxx" with one line of text: "help".
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: variations on your account-authority model
the trivial business process scenerio isn't that it is a central IBM
mainframe, or it is a clusterd-distributed open system and/or whether
or not there is back-up. The X9.59 model (and AADS) is that the
signature authentication is done at the point that the transaction is
approved. seperating the authentication of the transaction and the
approval/execution of the transaction is one of the things that
creates systemic risks.
Seperating the authentication from the transaction approval/execution
doesn't improve the availability of the system ... because if the
decision point that executes the transaction is down ... having the
authentication part up and running does nothing.
This isn't a centralized or decentralized issue ... this is coupling
the approval, authentication, and execution into a single business
operation ... which actual improves the availability as well as
reducing systemic risk.
Having three different things that all must be up is the product of
their individual availability ... it is only when the three things all
can each complete the operation that you have availability of "one
minus the product of their invididual non-availability". Three
serialized processing units each with .95 availability have a business
process availability of ,86. Three independent operations, each
capable of completing, and each having a .05 non-availability has a
business process availability of five-nines (i.e. .999998).
This isn't an issue of private & public CA .... AADS just integrates
digital signatures into the standard financial business processing
model ... instead of creating an independent authentication process.
At the same time ... it doesn't preclude or exclude CADS for
non-financial processing transactions. A person, if they wanted to,
might choose to register the same public key with multiple authorities
... in the same way they open multiple accounts and sign multiple
signature cards.
For help on using this list (especially unsubscribing), send a message to
"dcsb-request@xxxxxxxx" with one line of text: "help".
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: variations on your account-authority model
There are several differences between a Certification Authority
Digital Signature model (CADS) and an Account Authority Digital
Signature model (AADS).
Model two or AADS has the account-holder registering a public key with
their financial institution almost identical to the way a public key
is registered in CADS ... but no certificate is issued; the public key
just goes into the database. While the technical processing looks like
CADS ... the AADS business process just mimicks signing a signature
card when opening an account.
From a financial business standpoint, the AADS is really only an
electronic version of a signature. There is no reliance on a
certificate by the financial business process ... AADS strictly
emulates the existing business process but with a digital
signature. There is no worry about any liability associated with
somebody attaching meaning to a certificate/credential since there are
none.
In a CADS scenerio, with a certificate playing some role in a
financial transaction authentication process, the AADS model
eliminates extraneous computational intensive cryptographic operations
associated with validating the certificate (and/or any certificates in
a CA-hierarchy). The X9.59 payment object requires a single digital
signature and a single digital signature verification.
Also in a couple meetings with some very smart financial folks this
past week, it was pointed out that the lack of certificates and
Certification Authority (especially one independent of the financial
house) eliminates systemic risks to financial infrastructure
associated with various kinds of Certification Authority &/or
certification private key failures. Compromise of individual private
keys can still occur but there is no systemic compromise of the
infrastructure.
NSCC relying on a certificate (and therefor the real-time integrity of
the CA's infrastructure) only for registration (and not for any
financial transaction approval or processing decisions) could
significantly mitigate the systemic risk to the financial
infrastructure (except possibly attacks involving re-keying of
accounts).
To some extent X9.59 (and my work on AADS) has been:
- KISS
- exactly mimick the existing financial business processes
where possible
- eliminate unecessary computational intensive cryptograpic
operations
i.e. looking at how signatures operate in the existing account-based
financial business processes and simply translating that into digital
signatures resulted in realizing that certificates were superfluous
(in this specific instance).
X9A10 is a working group in X9A (some information at
http://www.x9.org/).
At the moment on the web there is only a
presentation by chair of X9A10 (Tom Jones) given at the July EPF
meeting (check July presentations at
http://www.epf.org/).
For financial transactions, my guesstimate has been the trade-off is
some where around 5% participation of accounts where independent
certification pilot implementations and core-processing integration
cross over. AADS-model assumes core-processing integration, so it
requires more upfront commitment by a financial institution (but the
business costs should scale much better since it is now part of the
normal operation).
I can take your CAIP invitation to the appropriate FDC business
people.
For help on using this list (especially unsubscribing), send a message to
"dcsb-request@xxxxxxxx" with one line of text: "help".
AADS/CADS complexity issue
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: AADS/CADS complexity issue
There is no need for the registration authority (AADS) to communicate
any compromise if there has been no trust propagation via a
certificate.
We have looked at three registration options/scenerios for financial
AADS:
- owner generates random seed and random public/private key
pair. owner communicates the public key to the AADS along with some
proof of knowing the private key
- interactive session between the account-authority and the owner,
where the account-authority provides part of the random seed that goes
into the public/private key generation. there are some hardware boxes
that provide extremely strong random seed values. A financial
institution might decide that the such of such a box would improve the
key generation.
- A financial account-authority may use a hardware box to generate
strong private/public key pairs and transmit both keys during a
session. Assuming that the specific private key is only used in
financial transactions at the account-authority there is no issue of
non-repudiation (i.e. there are more easier ways for an untrustworthy
financial institution to generate bogus transactions against a
customer's account ... than going to the trouble of a private key
transaction).
A purpose of a certificate is trust propagation. If an AADS is not
interested in trust propagation, then it doesn't gain anything by
signing a certificate (and in fact, opens itself to trust propagation
when none was intended). Not signing a certificate eliminates
the possibility that an AADS's trust is propagated.
Whether or not an AADS chooses to support trust propagation should be
strictly a business decision, and therefor the manufacturing of a
signed certificate should be a business decision.
Furthermore, there is nothing that would prevent a user from
generating a self-signed certificate or for the user to use the same
public/private key pair in registration with multiple different
authorities (some of which might support certificate signing).
I've theorized that the issue of liability insurance for CADS might be
viewed as a bug in the business model. Certificates potentially open
the authority up to an unlimited number of uses for unconstrained
types of uses. An AADS choosing to operate w/o certificates totally
eliminates that bug. All transactions come to the AADS for approval,
and therefor it knows each instance and type of use (eliminating trust
propagation and the potential unwanted liability side-effects).
For help on using this list (especially unsubscribing), send a message to
"dcsb-request@xxxxxxxx" with one line of text: "help".
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: AADS/CADS complexity issue
The AADS/CADS complexity issue is actually quite trivial from the
technical standpoint ... it is whether the certificate flows thru with
the transaction or not ... and is very straightforward option to
support. The business process implications of depending on the
certificate infrastructure which reduces the integrity of the
transaction and introduces additional unnecessary systemic risk is
significant..
The real complexity of the domain of x9.59 transactions isn't in the
AADS/CADS option but in providing the virtual document processing
necessary to compensate for existing legacy networks (that will carry
the transaction). For the different types of transactions and
networks, they do seem to share the characteristic of supporting
optional fields for transactions.
X9.59 examines the types of existing fields in transactions arriving
at the financial institution for execution and determines which of the
fields contain values known to the originator of the transaction. This
is going to be different for the different types of financial
transactions and networks. For each type, X9.59 defines a virtual
document that consists of
- canonical representation of the values known to the originator
(and to the financial institution)
- additional values necessary for the integrity and/or cryptographic
strength of the transaction.
The originator of the transaction creates the x9.59 virtual document
(appropriate to the type of transaction) and signs it. The originator
then creates an x9.59 opaque object that consists of the signature of
the virtual document and any of the necessary additional values. The
transaction-type unique x9.59 opaque object is pushed with the
transaction. At the point where the transaction enters the legacy
network, the x9.59 opaque object is placed in some type of addenda
field.
When the transaction and x9.59 opaque field arrives at the financial
institution, the same virtual document must be rebuilt from a
combination of transaction values and values from the x9.59 opaque
field. Then the digital signature of the virtual document can be
verified from the public key in the account record.
The AADS/CADS option processing (i.e. certificate or no certificate)
in the transaction is technically trivial compared to the virtual
document complexity processing that will be unique to each kind of
legacy transaction.
Note x9.59 is only defining the payer to payee formats. However, the
x9.59 opaque field will tend to be unique to the type of payment
transaction. For the rest of the processing, X9.59 is only defining
the integrity requirements and that the x9.59 opaque field is carried
with the transaction through to the payer's financial institution (and
that the payer's financial institution perform digital signature
verification on the transaction using the contents of the x9.59 opaque
field).
For help on using this list (especially unsubscribing), send a message to
"dcsb-request@xxxxxxxx" with one line of text: "help".
parsimonious
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: parsimonious
i afraid i spent some amount of my career on processor and kernel
products ... it left a legacy of reducing things to atomic units
... that with a long career supporting business operations ... results
in a tendency to forcing a match between atomic units and business
processes (and making sure they are industrial strength ... so
preferably they never fail and/or all their failure modes are well
understand and manageable/recoverable).
if there is a real reliance on certificates in a business process
... then from a industrial design point-of-view the certificate
infrastructure may have to meet the same industrial engineering
requirements as the rest of the business process implementation. this
also relates to my previous comments about removing systemic risks
from mainline financial business processing.
I once had a hostile I/O environment which generated hundreds of
faults per day (normal operations wouldn't see these faults more than
once a year). An industrial strength mainframe system tended to fail
within 15 minutes of coming up in this environment. I undertook to
completely rewrite the input/output subsystem so that all possible
fault scenerios were handled and the IOS could never be a cause of a
system failure ... even after they significantly increased the size of
the hostile environment.
For help on using this list (especially unsubscribing), send a message to
"dcsb-request@xxxxxxxx" with one line of text: "help".
AADS & X9.59 performance and algorithm key sizes
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: AADS & X9.59 performance and algorithm key sizes
An interesting analysis of AADS is the incremental delta of EC-DSS
(see recently passed x9.62) in an account authority environment. Given
a 200-300 byte account record, there is a major incremental difference
between a EC-DSS public key field and a RSA public key field. The
impact is not only to the difference in relative disk space increase
for the account file size (possibly a 10% increase vis-a-vis a 100%
(or more) increase ... i.e. to add a public key field to every
existing account record) ... but also the impact on I/O bus
utilization as well as hardware, system, and DBMS cache efficiencies
(&/or requirements) when the records are read, processed, updated
and/or written.
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: AADS & X9.59 performance and algorithm key sizes
part of the problem is that lots of the real numbers are business
sensitive.
not too long ago come off a small pilot project involving introducing
new type of processing for 60 million of the accounts ... overall
infrastructure might avg 1000 trans/sec during peak hrs ... the 60
million is only subset of the total environment. One of the
interesting things is that the few cents is somewhat variable
depending on what the client has selected for the accounts in their
portoflio ... and therefor what they are charged for a trans. there
are something like 170 optional features (before we started our
project) that might be selected for processing for an account in
particular portfolio ... and that is even further broken up with
different groups of accounts within a portfolio having different
processing options (like gold cards might be slightly different from
platinum cards might be slightly different from regular cards). The
feature selection somewhat varies the processing costs as well as what
is priced on a per transaction basis.
i can relate to your new technology scenerio. several years ago
i was doing something for the largest online system in the world
(i.e. at the time they would avg upwards of 4000 trans/sec during
peak hrs) ... they had an application that represented something
like 25% of the system and they had a list of ten impossible things
that they needed to do. I went away for 2 months and taking a totally
different paradigm approach redesigned and re-implemented
their application from scratch and came back and demo'ed
it. I had also speeded it up by a factor of 100 ... but since one
of the 10 impossible required 10* the processing ... it only
netted about 10* performance increase (although I did collapsed
4 human transactions into a single operation so the elapsed
human time improved by a much larger factor). They didn't know
what to do with it. Part of the problem was that they possibly
had upwards of 1000 people supporting the application as
it was ... the new paradigm reduced the support requirements
to possibly 25-35 (in part, some of the impossible things were
impossible because they had 1000 people involved).
To introduce the revised application would
have had enormous organizational impact. This turned out
to be more significant than not being able to perform their
ten impossible things.
The key-length field size is just one of the issues raised in a
CADS->AADS paradigm shift.
Another issue that sometimes has been hard to come to grips with is
the liability issue ... it becomes much simpler.. Without
certificates there are no certification authorities, without
certification authorities there is no certification, without
certification there are no relying parties relying on certification
done by trusted third parties, without relying parties relying on
certification done by trusted third parties there is no liability,
without liability there are no legal discussions, government CA
associations, state legislation, federal legislation, UN guidelines,
CA policies and practices statements, liability limitation statements,
etc. It is remarkable what happens sometimes when you shift the
paradigm.
All of this is propagated when the CA digitally signs a certificate
that attests to some binding between a public key and some identity or
set of attributes ... that a relying party becomes dependent on (and
can totally disappear in a AADS infrastructure). There still may be
individual liability depending on how their digital signature on a
transaction is treated. If signature is on a financial transaction
... then it could be treated as a more secure form of pin
authentication ... in which case it can fall totally within existing
regulations. For deployment then some of the hardest becomes where to
sprinkle a couple hundred lines of code in several different places
(all dependent on, of course, on a highly trusted crypto library).
AADS & X9.59 performance and algorithm key sizes
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: RE: AADS & X9.59 performance and algorithm key sizes
the scenerio goes both ways ... government providing identification
certificates that population use when opening accounts and therefor
meeting government "know your customer" mandates. problem is that
government would have a hard time funding an infrastructure for such a
single use. the other side is that financial institutions are less
concerned about DNA-like identity and more concerned with
"credit-history" identity ... these are somewhat a disjoint set.
the major scenerio proposed for certificates so far are the "comfort"
certificates for internet electronic commerce. merchant electronic
commerce servers present a "comfort" certificate indicating an entity
that represents a great deal of comfort to consumers stands behind the
merchant (and certified that the merchant meets certain standards).
In fact, consumer comfort certificates seem to be applicable to
wide-range of webservers.
Comfort certificates are view as part of electronic commerce but
outside the x9.59 payment architecture ... since the comfort
certificate isn't necessary to guarantee the integrity of the
financial infrastructure. The consumer's digital signature on the
payment instruction (with the rest of the processing) is sufficient to
guarantee the integrity of the financial infrastructure. Another
property is that since there is no consumer certificate ... the
associated privacy exposure has been eliminated.
Major objectives of x9.59
- stronger integrity than other payment protocols
- integrity achieved w/o requiring encryption
- maximize privacy while working efficiently (and not requirig
encryption)
- work in all electronic payment environments, not restricted
to just internet/web ... but also support things like POS,
ATM, settop boxes and new forms not yet thot of.
and one of my favorites: KISS
Human Nature ... a little cross-posting
From: Lynn Wheeler
To: dscb@xxxxxxxx
Subject: Re: [E-CARM] Human Nature ... a little cross-posting
original premise was somewhat that a purchase order authorization
system could be re-engineered to be certificate based ... effectively
with certificates carrying authorization attributes necessary for the
PO infrastructure to operate
From: Lynn Wheeler
To: <e-carm@xxxxxxxx>
Subject: Re: [E-CARM] Human Nature
certificates provide a new way of binding a set of attributes together
... typically in conjunction with a public key.
for years business has used account records to perform similar
functions, attribute binding ... and frequently in conjunction with
authorization and even authentication attributes (even for
non-face-to-face transactions, pins, id-numbers, mothers-maiden-name,
etc have been used as mechanism for authentication). even if a small
number of these attributes were moved from account records into a
certificate ... there haven't been many proposals so far indicating
that all attributes could be moved to a certificate and account
records done away with. For instance real time status attributes,
current disposition of the order, has it left the loading dock, what
is the shipping tracking number, has the order been billed net-30,
net-60, net-90 ... would there be aggregation of orders for billing
and has the bill been sent and/or paid ... possibly hundreds of
attributes in total ... only a small number of which have been
considered for re-engineering into certificates.
conversely it is relatively straight-forward sequence to go the other
way ... rather than binding re-engineering all the attributes of
business into certificates ... add public key registration to an
account record ... so that account record bindings include a public
key for authentication ... so that public key is added to the other
forms of authentication and digital signature is added to forms of
authorization.
certificates do have the seductive quality of apparent ease of adding
attributes in a non-centralized, distributed manner. a problem crops
up in real-world business where subtracting/nullifying is as important
and sometimes more critical than adding. technology for flushing
nullified certificates has been moving more & more towards centralized
operation ... resulting in certificate operation looking more and more
like account management ... at which point it is account-based
management with this thin veneer of superfluous certificate wrapping.
From: Lynn Wheeler
To: "e-carm" <e-carm@xxxxxxxx>
Subject: Re: [E-CARM] Human Nature (example)
lets say that individual has PO signing authority for individual
purchases up to $1000 with a specific supplier to not exceed $10,000 a
month with that supplier ... assuming that at the supplier the company
has had its bills paid and the "account" is in good credit
standing. furthermore, the individual's departmental monthly budget is
$50,000/month and $400,000/year (across all supplier's).
scenerio is that digitally signed purchase order goes to the
accounting office for verification that the account that the overall
accont numbers are in good standing ... at which time the accounting
department updates the departments account record and digitally signs
the PO and sends it to the supplier.
The supplier checks the account department's digital signature against
what is on file ... and verifies the company's account is in good
credit standing. The supplier then updates the account record for the
company and cuts a order.
The supplier doesn't really need to know the public key of each
individual able to cut purchasing orders ... just the public key of
the authorizing department (since it isn't likely the supplier can
making any authorization judgements about internal corporate budgeting
proceedures)
Going with just a certificate binding with an individual's public key
as sufficient to both authenticate and authorize a purchase order is
usually too simplistic ... since the actual authorization process can
involve a multiplicity of highly dynamic & complex states as well as
dynamic state aggregations ... effectively impossible to represent in
a certificate binding architecture.
Digital signatures provide for strong authentication in an account
based environment ... when the public key(s) has been registered in
the account record ... and the account record represents the binding
of real world complex & dynamic authorization attributes.
Playing out authorization attributes in certificates creates
opportunity for fraud because the certificate authorization attributes
are unlikely to represent real-time states and/or state aggregations.
AADS, X9.59, security, flaws, privacy
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dscb@xxxxxxxx
Subject: AADS, X9.59, security, flaws, privacy
The other fraud play is the separation of authentication and authorization.
Several existing payment protocols separate authentication and
authorization and this separation opens up opportunity for fraud. At
very high level ... almost all security paradigms recognize that if
authentication and authorization are separated ... that represents a
hole in the security and a potential for breaches to occur.
In X9.59 protocol mappings, AADS at the consumer's financial
institution is used to authenticate the consumer's digital signature
(and the transaction) as well as using the rest of the information in
the account record to authorize the transaction.
In practice, not only are the merchants primarily interested in
knowing that they would be paid ... but if other than the consumer's
financial institution authenticate a transaction ... when the same
entity isn't also authorizing the transaction represents a security
flaw. Furthermore, in a x509 certificate-based scenario ... there will
also be privacy issues involved with the consumer unnecessarily
divulging personal information to a merchant.
A very fundamental rule of security is never separate authentication
and authorization.
A very fundamental rule of privacy is never unnecessarily divulge
personal information.
Having a merchant authenticate anything (when it isn't also
authorizing it) is at best superfluous work ... assuming that the
consumer's financial institution also authenticates the same
information and at worst a security flaw (if turns out to not be
superfluous).
Use of X509 certificates tend to be a privacy violation ... and since
the certificates are available ... there will also be a tendency to
perform some sort of authentication; such authentication is either
redundant (and therefor superfluous) or a security flaw (if not
redundant).
Also, in the X9.59/AADS scenerio there is the efficiency issue
... both from the technical processing stand point as well as from the
business process operational stand point. X9.59 simply would add a
digital signature to existing payment instruction.
Fron a technical processing stand point there is a very modust
increase in resources used (message size, handling, etc) since it
basically represents the addition of a digital signature to an
existing message.
From a business process operational stand point the efficiency
improvement is even more significant. It is effectively the current
infrastructure, the same business operations and no new or additional
distributed parties (requiring regulatory or other administrative
infrastructure changes, including issues regarding liability).
This also leads to the systemic risk issue. Since there is no
seperation of authentication and authorization, the associated
security flaws are eliminated. Also, since the authentication and
authorization are combined there is no distributed operation failure
modes (i.e. the authorization/authentication party ... the consumer's
financial institution has no responsibility for contacting any outside
agent regarding things like CRLs, current status, etc). Furthermore
there are no new single point of failure attacks/failures (like the
issuing CA and/or the CA's signing key).
AADS & X9.59 performance and algorithm key sizes
From: Lynn Wheeler
To: dscb@xxxxxxxx
Subject: AADS & X9.59 performance and algorithm key sizes
there is sometimes a compelling business reason for creating security
holes with seperation of authorization and authentication ... but that
doesn't eliminate the basic premise that the seperation opens up
security exposures. In a DMV case, driving ability, eye-sight and
address are a number of things that might change (although not
nomarlly birthdate) .... and have been some of the things assessed as
to cost to close the holes against the risk exposure.
Driver's licenses have been used to authenticate check acceptance in
totally offline environment ... this is a scenerio where there is a
enormous hole with seperation of authentication and authorization; the
use of driver's license doesn't eliminate the hole ... it is used to
try and make the hole slightly smaller.
In the case of birthdate, much of the liability (created by speration of
authentication and authorization; security talks about security holes,
business uses liability in similar way) is created by the same government
infrastructure responsible for the DMV ... and is much simpler for them to
specify that driver's license is sufficient due diligence to authenticate
birthdate. The security holes created by the seperation (or the liability
when speaking businessees) gets more complex in financial arena since it
very likely involves different business entities.
Having legislation limit the liability ... doesn't mean that the liability
(created by the seperation) doesn't exist ... just means that government
has decided to regulate it for some reason.
For help on using this list (especially unsubscribing), send a message to
"dcsb-request@xxxxxxxx" with one line of text: "help".
dbts: More on law vs economics
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: dbts: More on law vs economics
some misc. related factors.
span of control for governments (& corporations) have periodically
been considered limited base on speed of communication or travel (ala
the roman roads) or management of complexity. Technology applied to
areas other than financial infrastructure can improve efficiency and
reduce costs in communication & management area ... which would argue
for enabling larger organizations ... rather than smaller.
in fact, one current critical, enabling technology at the basis for
much of the transition to information age ... is very complicated,
very expensive chip fab lines. it is hard to see how any of this would
continue to operate w/o massive financial & organizational
aggregations that are behind creating & sustaining those
fab. lines. W/o the scale, expense and complication of those fab lines
... the necessary technology enablers would be likely be 100* (or
more) expensive (and at least one argument is transitions will occur
because less expensive .... there is transition to the less expensive
alternatives .... but much of this wouldn't exist if the $300
computing devices were $30,000 instead).
While application of new technology in various areas .... may lead to
obsoleting various organizations that had been necessary for managing
complexity and scale .... the new technology has in turn its own
dependencies on large, complex organizations that require massive
financial aggregation .... which in tern has various orgnaizational
dependencies (design/development, sales, marketing, distribution
channels, outlets, revenue aggregation, etc). Would you gamble couple
billion on new fab line .... if you weren't confident of operations &
conditions in place that would allow recovering the investment?
Conversely, it is how to imagine how the current opportunities would
have come into being .... and/or will continue to exist w/o massive
financial aggregation ... and the organizations that go with its
support.
For help on using this list (especially unsubscribing), send a message
to "dcsb-request@xxxxxxxx" with one line of text: "help".
Statistical Attack Against Virtual Banks (fwd)
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Re: Statistical Attack Against Virtual Banks (fwd)
i think that a distinction can be made between using digital signature
for strong authentication in conjunction with financial transactions
and needing a x509v3 identify certificate for validating the digital
signature. in fact, x509v3 identity certificattes can introduce
unnecessary systemic risks and/or unnecessarily impact privacy
information.
i believe design point of public key certificates introduced "binding"
of public key and other information for environments that lacked any
binding infrastructure (i.e. offline email paradigm from the early to
mid 80s). banks & other business operations have long had business
processes and high integrity binding infrastructures in their account
records ... adding public key binding to account records for online
transactions eliminates having to duplicate an extraneous binding
infrastructure which can be prone to referential integrity problems
and relying on stale &/or out of date information at the time the
certificate was manufactured as well as unecessary business processes.
For help on using this list (especially unsubscribing), send a message to
"dcsb-request@xxxxxxxx" with one line of text: "help".