dual-use digital signature vulnerability

[Anne & Lynn Wheeler]

At 05:37 AM 7/22/2004, Amir Herzberg wrote:
>Most (secure) signature schemes actually include the randomization as part 
>of their process, so adding nonces to the text before signing is not 
>necessary. OTOH, I don't see any problem in defining between the parties 
>(in the `meta-contract` defining their use of public key signatures) that 
>the signed documents are structured with a random field before and after 
>the `actual contract`, as long as the fields are well defined.


there has been some claim that large random nonces as part of message ... 
before hashing and signing is characteristic of RSA signatures. one of the 
issues with DSA and hardware tokens in the 90s was that none of the 
hardware tokens had reliable random generators. If you were doing DSA (or 
ECDSA) infrastructure ... then integrity was dependent on quality random 
generator as part of the signature process (to preserve the integrity of 
the private key). In some sense, large random nonces (as part of the 
content to be signed) was shifted to the party(s) generating the message as 
part of the RSA process. In theory, DSA/ECDSA eliminates that requirement 
... especially as you move in to the late 90s where hardware tokens started 
to appear that had quality random generators.

protocols have had severs contributing unique values in signed messages 
.... in things like authentication protocol .... as countermeasure to 
replay attacks (on the server).

protocols have had clients contributing some values in signed messages ... 
in an authentication protocol ... as countermeasure of server attacks on 
clients. It isn't necessary that the client contributed part has to bracket 
both the start and end of the message .... in a digital signature 
environment ... since the digital signature protects the whole message 
integrity. The client contributed part could be simple readable text 
disclaimer ... comparable to some disclaimers you see at the bottom of 
emails (especially from lawyers, doctors, and/or people that work for such 
firms .... you even see it in various mailing lists by people that work for 
the big accounting firms).

sometimes the recommendations are that both server and client contribute 
something unique to the signed message ... as generic countermeasures ... 
regardless of whether the situation is actually vulnerable to the 
associated attacks. In general, where the server incurs some expense and/or 
liability associated with every message ... the server (or relying-party) 
is probably interested in countermeasures against replay attacks.

one of the requirements given x9a10 working group (for the x9.59 protocol) 
... was to be able to perform the operation in a single round-trip .... w/o 
any sort of protocol chatter. this is comparable to existing electronic 
payment business process. the countermeasure that the infrastructure uses 
for replay attacks is to have the transactions time-stamped and log is 
kept. transactions with time-stamps that predate the log cut-off are deemed 
invalid. In the x9.59 transaction scenario ... the signing entity (in 
theory) specifically approved every transactions and used ecdsa signature. 
the ecdsa signature would preserve the integrity of the transaction. the 
time-stamp in the transaction would indicate whether it was within the 
current active log window of the payment processor, and the randomness of 
the ecdsa signature would provide uniqueness (two transactions that were 
otherwise identical (in amount, time, etc) would be unique if they had 
different ecdsa signatures (effectively provided by the definition of dsa & 
ecdsa).

the addition of ecdsa signature to existing payment transaction .... 
exactly preserved all the existing business processes and flows ... 
including the requirement that the client can originate the transaction and 
the message flow could complete in a single round-trip.

the addition of the ecdsa signature added
a) integrity of the transaction message,
b) authenticated the origin, and
c) provided transaction uniqueness.

no (public key) certificate was required since the transaction was being 
processed by the relying-party (which in the SET model was also the 
relying-party, had the public key on file, had the original of all the 
information that went into a SET relying-party-only certificate, and the 
only function that the SET relying-party-only certificate was to repeatedly 
travel from the client to the relying party increasing the payload and the 
bandwidth requirements by a factor of one hundred times, carrying static, 
trivial subset of information to the relying party ... which the relying 
party already had ... making it redundant and superfluous ... other than 
contributing enormous payload bloat).

there was one additional thing that was specified in x9.59 standard .... 
that account numbers used in x9.59 transactions could not be used in 
non-authenticated transactions (not that all the payment processors already 
supported feature/function of mapping multiple account numbers to the same 
account). the issue was that it was recognized that regardless of the 
crypto facilities used to protect the account number in flight, there were 
scores of business processes that required the account number to appear in 
the clear.

In the existing infrastructure that are huge numbers of unauthenticated 
transactions that can be performed with the account number ... which 
effectively turns the account number into an enormous shared-secret .... 
requiring enormous amounts of protection for the shared-secret. however, 
with all the enormous numbers of places that the clear-text account number 
is used ... it is not possible to also preserve the account number as a 
shared-secret. minor past note about security proportional to risk
<http://www.garlic.com/~lynn/2001h.html#61>http://www.garlic.com/~lynn/2001h.html#61 


so the x9.59 approach was to eliminate "shared-secret" as a business 
characteristic of the account numbers used in x9.59 transactions. if an 
account number used in an (digitally signed) x9.59 transaction ... can only 
be used in x9.59 (digitally signed) transactions .... it no longer carries 
with it the "shared-secret" characteristic (since simple knowledge of the 
account number is insufficient to impersonate and/or perform fraudulent 
transactions).  So if the insiders at a merchant processing end-point (or 
an external outsider that is harvesting merchant processing transaction 
files) is unable to "steal" the account number and use it fraudulently ... 
it no longer has to be protected as a shared-secret.

The end-point static harvesting of transaction files has been the major 
vulnerability for a long time. They have tended to be in the clear because 
of the large number of business processes that require access to the 
transactions. Neither SET nor SSL provided any countermeasures for this 
(the major) vulnerability/exploit.

X9.59 did eliminate this as a vulnerability ... since stealing the 
transaction file and harvesting the account numbers .... would not provide 
the crook any mechanism to impersonate and/or perform a fraudulent 
transaction. It turns out the secondary effect was that it was no longer 
necessary to hide the account number while in flight either (in order to 
preserve an account number as a shared-secret). digitally signing the 
transaction both preserved the integrity of the transaction as well as 
authenticating the origin of the transaction. This then eliminated the 
requirement to hide the account number as a countermeasure against the 
account number being exposed (and comprimising its shared-secret 
characteristic).

The issue with SET was that it was horribly more complex and expensive and 
provided no fundamental additional protection/countermeasure than existing 
SSL (with respect to reducing existing vulnerabilities and fraud).  This 
was somewhat orthogonal to the problem with the horribly additional expense 
not being born by the primary benefiting parties.

X9.59 is an enormously simpler and less expensive protocol than either SET 
or SSL ... and turns out to address (in a business way) the major exploits 
and vulnerabilities in the existing infrastructure ... the basic 
characteristic that the account number is effectively a shared-secret 
(which neither SET nor SSL addresses). Furthermore, with the elimination of 
the shared-secret attribute for account numbers .... then it is no longer 
necessary to encrypt the transmissions (for purposes of preserving the 
account number secrecy).

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com