dual-use digital signature vulnerability

[Anne & Lynn Wheeler]

At 10:36 AM 7/18/2004, Sean Smith wrote:
>In SSL and TLS, the client isn't signing random data provided by the 
>adversary.  Rather, the client is signing a value derived from data both 
>the client and server provide as part of the handshake.  I do not believe 
>it is feasible for a malicious server to choose its nonces so that the 
>resulting signature be coincide with a valid signature on a delegation 
>cert the client might have constructed.

the issue in the EU FINREAD scenario was that they needed a way to 
distinguish between (random) data that got signed ... that the key owner 
never read .... and the case were the key owner was actually signing to 
indicate agreement, approval, and/or authorization. They specified a 
FINREAD terminal which supposed met the requirements that the key owner had 
to have read and to some extent understood .... and approved as to the 
meaning of the contents of what was being signed.

However, the FINREAD specification didn't define any mechanism that 
provided proof to the relying party that a FINREAD terminal was actually 
used as part of the signature process.

Some of the non-repudiation service definitions also talk about processes 
that would provide high likelyhood that the person performing the signing 
has read, understood, and agrees with the contents of what is being signed. 
However, many of them fail to specify a mechanism that proves to a relying 
party that such a non-repudiation service was actually used.

so the dual-use attack .... is if a key-owner ever, at any time, signs 
something w/o reading it ... then there is the possibility that the data 
being signed actually contains something of significant.

if there is never any proof, included as part of the integrity of the 
message ... that proves to the relying party that some sort of 
non-repudiation environment was used as part of the digital signing .... 
then it falls back on requiring an exhaustive proof that never in the 
history of the private key was it ever used to sign contents that were 
unread and could possibly be random.

it isn't sufficient that you show there is some specific authentication 
protocol with unread, random data ... that has countermeasures against a 
dual-use attack ... but you have to exhaustively show that the private key 
has never, ever signed any unread random data that failed to contain 
dual-use countermeasure attack.

the alternative to the exhaustive proof about every use of the private key 
.... is strong proof (that is built into the integrity of the signed 
contents) that non-repudiation environment was used for the digital signing 
(strong implication that the key owner, read, understood, approves, agrees, 
and/or authorizes the contents of the message).

the NIST scenario for a exhaustive proof ... rather than exhaustive proof 
about every use of a specific private key .... would be able to show that 
it is impossible to use the private key in any protocol not written by the 
people making the presentation

this came up in a SET discussion long ago and far away. it was about 
whether there was every any SET gateway protocol that could set the 
"signature verified" bit in the ISO 8583 message. One of the SET vendors 
claimed that the software they shipped was certified that it would never 
set the "signature verified" bit in the ISO 8583 message, if the signature 
hadn't actually been verified (and therefor there wasn't an infrastructure 
vulnerability). The problem was that they had created an infrastructure 
that didn't require end-to-end proof of the signature verification ... and 
they were unable to control that every ISO 8583 generated message .... was 
certified as only being able to be generated by their code.  They had 
created an infrastructure vulnerability .... that allowed a wide variety of 
software to be used .... and was only safe if they could prove that every 
copy of code generating every ISO 8583 messages was their code and it was 
impossible to modify and/or substitute something else in the generation of 
an ISO 8583 message.

The countermeasure to the seriously flawed SET design requiring exhaustive 
proof that every ISO 8583 message that was ever created that carried the 
"signature verified" bit .... could have only been created by unmodified, 
certified software .... was to support end-to-end authentication. .And for 
a slight drift ... that wasn't practical in the SET design because the 
inclusion of a certificate would have represented horrendous payload bloat 
of two orders of magnitude (discussed in some detail in recent posts to 
another thread in this mailing list)


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

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