[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
three digital signature models ... for x9.59
Three digital signature models are described; the original "offline"
model and two newer "online" models. 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 certificate 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 revokation 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/merchant does a real-time authorization with the
account issuing institution. The consumer's digital signature is
forwarded by the merchant 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 certificate 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 certificate 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/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
consumer can be offline and transmits an order and payment
instructions via methods like email (not requiring real-time, online
interaction with the merchant). In the validation process, there is
an issue whether the merchant is also offline at the point that it
approves the transaction. If the merchant is offline, then it needs a
consumer certificate to validate (and authorize) the consumer
transaction. If the merchant 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 merchant 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.
Follow-Ups: