Is there any future for smartcards?

[Anne & Lynn Wheeler]

Dave Howe wrote:
>   TBH I don't think the smartcard approach will work - really, everything needed
> to verify what you are signing or encrypting needs to be within your secure
> boundary, so the only sensible approach is for a mobile-sized cryptographic
> device to be autonomous, but accept *dumb* storage cards for reading and
> writing; that dumb card can then be used to transfer a unsigned document to the
> cryptographic device, which when inserted uses a relay or switch to assume
> control of the keyboard and screen; person wishing a digital signature stores
> the document to be signed onto the card; signer inserts into his device, uses
> the device's display to assure himself this is really what he wants to sign and
> then keys his access code. The device then produces a digital signature
> certificate (possibly deliberately adding some harmless salt value to the end
> before signing, which is noted in the detached certificate's details) and copies
> that to the dumb card, retaining a copy for the user's own records.
>   by using a switch controlled by the cryptographic module, the display can be
> then used by an alternate system when not in use - for example, a mobile phone -
> while providing an airgap between the secure module and the insecure (and yes,
> this would mean if you received a contract via email, you would have to write it
> to a card, remove that card from a slot, insert it into a different slot, then
> check it. I can't see how the system can be expected to work otherwise....)

part of the issue may involve semantic confusing digital signature and
human signature (possibly because they both contain the word signature)

from 3-factor authentication paradigm

* something you have
* something you know
* something you are

... fundamentally a digital signature verification by public key is
basically a form of "something you have" authentication (aka the private
key contained uniquely in a hardware token).

so, from a parameterized risk management and threat model standpoint ...
the issue is how many ways ... and how probable is the compromise of the
physical object ... such that the digital signature doesn't originate
from a specific hardware token in the possesion of a specific person.

the other stuff ... say related to issues attempting to be address by
some of the finread characteristics
http://www.garlic.com/~lynn/subpubkey.html#finread

where a digital signature may be used in conjunction with other efforts
and technology to imply a human signature ... which in turn implies that
the person had read, understood, approves, authorizes, and/or agrees
with what is being signed. this goes far beyond the straight-forward
"something you have" authentication that is implied by the verification
of a digital signature with a public key.

it also potentially opens up the dual-use attack ... where the same
technology is used for the original straight-forward authentication
purpose ... and as part of some sort of infrastructure implying read,
understood, approves, authorizes, and/or agrees.

the pki digital certificate work somewhat originally strayed into this
confusing the term *digital signature* and *human signature* (possibly
because they both contain the word *signature*) ... with the original
definition of the *non-repudiation* bit in a digital signature. The
scenario went that if the relying party could find and produce a digital
certificate w/o the "non-repudiation" bit set, then the relying party
could claim that a digital signature applied to some bits were purely
for authentication purposes. However, if the relying party could find
and produce a digital certificate (for the public key) with the
"non-repudiation" bit set, then the relying party claimed that was
sufficient proof that the person had read, understood, agrees,
authorizes, and/or approves the bits that had the digital signature
(in part, because there is nothing in normal PKI standards that provides
proof as to what, if any, digital certificate happened to be attached to
any particular digital signature).

Then came the realization that it was quite absurd that because a
certification authority had included the non-repudiation bit in some
digital certificate at some point way in the past ... that the setting
of that bit had absolute and total control of whether a person had read,
understood, agrees, authorizes, and/or approves some pattern of bits for
every digital signature that might be created in the future. The
absurdity of such an assertion was since lead to the non-repudiation bit
being depreciated.

in any case, the morphing of any digital signature for "something you
have" authentication into anything that could imply human signature goes
well beyond the secure boundary issues.

some past posts on dual-use attack
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/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
http://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing
and authorization in applets
http://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair
protection on Windows
http://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others
(without their private keys)
http://www.garlic.com/~lynn/2005m.html#11 Question about authentication
protocols
http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack





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