In comp.lang.java.advocacy, Roedy Green
<see_website@[EMAIL PROTECTED]
>
wrote
on Sun, 09 Sep 2007 07:01:39 GMT
<7367e35etej2knmruboe45n6uja649catt@[EMAIL PROTECTED]
>:
> It seems to me any sort of ID that can be forged for under $500 is
> worse than useless. Any serious bad guy can easily afford fake id.
> For everyone else it is just a hassle if they forget their id.
>
> In our past anonymity was not a right. Everyone knew everyone in the
> village/tribe. You could not easily do wrong without others knowing
> it was you.
>
> If we got serious about a Universal ID, what are its characteristics?
>
> 1. costs over $1,000,000 to forge.
Bear in mind that a dollar has not been properly
characterized, and that German marks just before Hitler's
ascendancy were more useful as heating fuel than as paper
denominations, in the early- to mid-1930's.
In short: a different metric is probably called for.
One useful one might be suggested by a French effort:
basically, it took about a week for a French server farm
to crack an SSL code of length 40 bits, some time ago.
>
> 2. not useful to anyone other than the true owner.
There are some interception techniques that might preclude
this requirement. In particular, the government might
want to reserve the right to prohibit transfers that are
not legal (e.g., drug-related), or even to fake transfers,
changing $10M to only $10, or modifying the destination
so that it goes into an escrow account that can later be
used as evidence of wrongdoing. Presumably, any would
require a court order, at least in the US (though one
wonders...but that's a diatribe for another newsgroup).
There are also issues between John Q. Public, private
citizen, versus John Q. Public, purchasing agent for
Amalgamated Ersatz. That may require the issuance of two
identities -- and one might leave the second to Amalgamated
Ersatz's purchasing agent manager.
>
> 3. can be scanned in under a second.
But cannot be scanned in less than about 0.1 second, to
forestall certain brute-force auto-attacks. (The same
logic is employed in logging into a computer today.)
>
> 4. cannot be scanned without permission from the owner.
There are multiple issues here. In particular, is this
a public/private system? Also, a biometric key may be
useful here -- retinal patterns would be almost impossible
to forge, although the eyeball measurement system might
then become the weak point. I believe you address this
point below.
A built-in timer/pseudorandom key might also be placed on
the card, synchronized (as best as possible) with a similar
timer at the master verifier. The verification system
would look at both timers in some form to ensure that the
key was in fact authorized by the card vendor. (The card
vendor, of course, might play some nasty games in that
area, but at least an independent hacker would have to do
some more work than simply sniffing the request/response.)
AFAIK, such smart timer cards are already in use, though have
yet to be connected to biometric data. Maybe next year. :-)
>
> 5. Should not need to be replaced unless lost. Additional photos
> could be digitally added as you age.
Face measurement techniques might be automated, not unlike
"aging software" reconstructions of missing children.
>
> 6. it should be useful as a credit/debit card, id card, door key,
> proof of age, link to medical records. It might even capture most of
> the information needed to compute your taxes in a way that the
> government has to believe you.
>
This is probably where we're going as a society, but
what's to prevent, say, ICE agents from de****ting someone
by perusing rental records or checking accounts?
> 7. It would have to be based on encryption technology and digitally
> signing information such as DNA, retinal patterns, fingerprints,
> photo.
Encryption tech is a means to an end, not unlike a ****eld
keeps the enemy's sword or knife from one's chest. In the
case of encryption, it hides the data from the casual sniffer,
and gives some assurance that the communications endpoint is
actually who the sender thinks it is.
>
> It might be reasonable to design such a card presuming the card will
> have the CPU and memory of a laptop running Java.
This feels orthogonal to Java in many ways, but it
certainly is possible to use a JVM as a driving machine
for the card's hardware. Bytecode, hopefully, is ROMable.
--
#191, ewill3@[EMAIL PROTECTED]
there, done that, didn't get the T-****rt.
--
Posted via a free Usenet account from http://www.teranews.com
|
