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 [EMAIL PROTECTED]
