Hagen Ladwig <hal22@[EMAIL PROTECTED]
> writes:
> In short, if you use digital signatures for example, they don't
> confirm 100% that you signed the do***ent, but with an error
> possibility of 10^-30 (I don't know to what parameters and system
> this would correspond, it is just a very, very small number).
nominally ... signing a do***ent (as in human signature) implies that
you have read, understand, aggrees, approves, and/or authorizes.
i've commented before (we had been called in to help word-smith the
cal. electronic signature legislation ... and later the federal
electronic signature legislation)
http://www.garlic.com/~lynn/subpubkey.html#signature
that there is appears to be semantic confusion since the word
"signature" occurs in both the term "digital signature" and the term
"human signature".
nominally digital signature is used to indicate 1) whether something
has been modified and 2) (authenticates) where something originated
a secure hash of something is taken and then encoded with a private
key ... resulting in a "digital signature"
the relying-party/recipient then takes the "something", recomputes the
secure hash, decodes the "digital signature" (with public key
corresponding to private key using in the original encoding) and
compares the two secure hashes. if they are the same, then the
relying-party/recipient can assume:
1) the "something" hasn't been modified since the "digital signature"
2) it originated from the party associated with the public/private
key pair
this can be assumed to be "something you have" authentication ... the
originating party has (unique) access and/or use of the associated
"private key" (i.e. some specific person is in physical possession of
a unique hardware token containing the only copy of a private key used
for the secure hash encoding).
however, nothing in this process carries the implication that the
originating party has read, understood, aggrees, approves, and/or
authorizes the contents ... just where the contents has originated.
this confusion has given rise to things like possible dual-use attack
scenario.
there are some number of authentication protocols ... where a server
generates and transmits a random number. the client digitally signs
the random number and returns the signature ... for "something you
have" authentication (random number used as countermeasure to replay
attacks). there is no presumption that the person associated with the
client is even cognizant of the random number value.
now if the same public/private key pair can be also used in
infrastructures that assume some equivalence to "human signature" (but
failing to provide any additional assurance as to human intent)
..... then you could potentially have an attacker compromising some
server ... and transmitting what appears to be a valid
transaction/contract in lieu of a random number (in an authentication
protocol). the digital signature is then automatically generated w/o
any implication of a human have read, understood, aggrees, approves,
and/or authorizes.
the countermeasure to dual-use attack ... is to always required that
there is additional indication as to whether there is any implication
of human signature, human intent, and/or read, understood, aggrees,
approves and/or authorizes.
another possible countermeasure ... is to *NEVER* use a private key in
any sort of digital signature based authentication protocol, where
something might be digitally signed that hadn't been read, understood,
agreed, approved, and/or authorized.
this strays into other assurance areas
http://www.garlic.com/~lynn/subintegrity.html#assurance
like the EU FINREAD terminal standard
http://www.garlic.com/~lynn/subintegrity.html#finread
where you have an independent, certified hardware token interface.
the high-assurance, certified terminal is provided with both a
pin-entry interface and display as countermeasure to
1) keyloggers that can capture hardware token pin-entry that can be
used by compromised software to generate operations for the hardware
token to digitally sign ... w/o the asssociated human's knowledge
2) compromised software that displays one thing but provides the
hardware token for something completely different for actual digital
signature (dipalsy a transaction for $5 but the actual digital
signature is for a transaction of $500).
the basic EU FINREAD terminal standard provided some protection to the
user against compromised software on their personal PC. However, there
is nothing in the basic standard that provides proof to a relying
party that such a terminal was used for the operation.
for the x9.59 financial standard, the x9a10 working group had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments
http://www.garlic.com/~lynn/x9.59.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
the x9.59 financial standard allows for (but doesn't mandate) both a
(hardware token) digital signature (for "something you have"
authentication) and a certified terminal digital signature.
the digital signature by the certified terminal, isn't so much for
authentication ... but as evidence (to a relying party) that certain
processes had been followed providing some basis for inferring human
intent as basis for human signature (i.e. read, understood, agrees,
approves, and/or authorizes).
the "digital signature" by the hardware token is simple "something you
have" authentication ... but does not imply "human signature". it is
the digital signature by the certified terminal that infers a process
that be used to imply human signature.
a couple recent postings dealing with digital signatures for
"attesting" something
http://www.garlic.com/~lynn/aadsm25.htm#35
signing all outbound email
http://www.garlic.com/~lynn/aadsm25.htm#44
TPM & disk crypto
and various past posts mentioning dual-use attack on digital
signatures
http://www.garlic.com/~lynn/aadsm17.htm#57
dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59
dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1
dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2
dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3
dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#56
two-factor authentication
problems
http://www.garlic.com/~lynn/aadsm19.htm#41
massive data theft at
MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#43
massive data theft at
MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#0
the limits of crypto and
authentication
http://www.garlic.com/~lynn/aadsm21.htm#5
Is there any future for
smartcards?
http://www.garlic.com/~lynn/aadsm21.htm#13
Contactless payments and the
security challenges
http://www.garlic.com/~lynn/aadsm23.htm#13
Court rules email addresses are
not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/2004i.html#17
New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#21
New Method for Authenticated
Public Key Exchange without Digital Certificates
|
