Skip to Content.
Sympa Menu

bluesky - uni id

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: "Josh" <josh AT mercuryfs.net>
  • To: "'Global-Scale Distributed Storage Systems'" <bluesky AT franklin.oit.unc.edu>
  • Subject: uni id
  • Date: Sat, 11 Aug 2001 16:23:49 -0700


Is this where I'm supposed to feel like I've been shot down? Oh yeah, here's
where I feel humiliated. Now... I'm going to reply, step by step, and lets
see if you stay engaged, or go back to the sidelines.... And yes, I do
appreciate you giving this conversation some life. Otherwise I wouldn't be
able to justify filling up everybodys inbox with this huge message.

As for the separate module plan, it will not eliminate anything, only make
it more of a hassle. My plan is to rely on NT's native credit card reader
that will eventually be made. That way, its Microsoft's problem, not mine.
Yeah, it don't yet exist, but I do believe card readers in keyboards will
become standard. I think by simply monitoring the underground, and offering
$50,000 rewards to the very people that crack the system, to create
something better, I can simply turn this problem onto itself. See, the Adobe
people screwed up by having the Russian arrested. They should have offered
his company a contract to improve the security. I don't you about you guys,
but I'm convinced this is the very best way to approach the problem.
Especially with a nearly open source design. All I know is that if I have a
budget to work with, I can greatly reduce this problem. Also, we could tie
it into NT's driver authentication routine, where a hash/crc (whatever) is
stored of the driver, and anything else but that wont be allowed to load.
God, why didn't they have that in windows 3.0, back in 1990? For Christ
sakes, to first validate what is to be loaded into the kernel has been a
part of mainframe operating systems forever (hasn't it?).

Separately, the fact is that hackers go after vulnerable credit card
databases, not the individual cards that fly thru the Internet. Ideally, you
get a separate credit card just for UNI ID, so the bill is just an audit
log, nothing else. Heck, make it a 100 dollar card. Plus, if you shut it
off, it doesn't effect your regular credit cards.

As for the animated files, I suck at web authoring. If you want to re do
them, once I get funding, I'll pay you for it..

As for the "no two people have the same credit card number" statement, I
also previously pointed out that it was an error. It should be "no two
people have the same credit card number and pin number". Once an account is
setup, it checks for a collision (an existing identical ID), and if there is
one, the end user must choose a different password (the "completion
password'). Therefore the issue is solved. If not, show me why. Also, note
the sub account # (value 63050). It exists to identify different accounts
using the same card.

As for the 3 passwords, it's a necessity. As stated earlier, the first is
your pin number that's used for authentication. Its low security because its
used often. The next is your private key, used for decryption, its high
security. The last is your account login password, when you need to change
your other passwords, or ID, and/or credit card number. As for the
usability, I'm not going to put everything into 1 password. That would be a
poor tradeoff.

As for uni-id being the private key keeper for groups, that is temporary.
What I'm really aiming for is something that can be emulated in NT's active
directory, or novell's NDS. That way, MFS can run on those platforms and
hopefully end up providing uni-id and pgp based security for accesses coming
from the Internet. This would achieve a level of transparency, where it all
appears to be the same from the outside, but you're running your native O/S
on the inside. That's the ultimate goal.

When I said I wasn't going to give people a long ID to remember, I was
referring to the method of appending your pin number to your credit card,
then hashing it. That's your ID. So your id is essentially a formula, you
need not memorize it. But you do need to remember what credit card you used.

As for vaporware, my stuff is NOT vaporware. Rather, its napkin ware. When
you have a design on a napkin, you have thus elevated yourself to a higher
level than vaporware. Especially if you got a 2" binder, soon to be 3", full
of stuff that looks like blueprints.

As for do I know anything about public key cryprography: I'm not an expert,
nor do I intend to be. But I have a good chance of talking my way into
funding, then hiring an expert. I claim to be a business man, who's
engineering is good enough to fool the venture capitalists. Hell, I'm going
to toss the uni id design to my attorneys within a few weeks (after I fill
it in)), and let them figure out if it will work or not. I love it, they
gotta research it, shit, let them deal with it!!! See, they don't want to be
embarrassed in their own field by patenting something that wont work! That's
a very very handy fact that I learned for an old client of mine. See, in a
way, its 2 birds with 1 stone...

As for using a bank for every transaction, authentications only occur at
login, or when a server is establishing a security trust with another
server. For all file system events other than this, the banks are not
involved.

As for how it works, and how it keeps your info confidential, here's the
details, and you need to reference figures 63 and 96. go to
www.mercuryfs.net/design/figures_index.htm. You also need to reference the
uni-id design (what exists of it at the moment).

Definitions:
The validator: is either your home PC, your work PC, somebody else's PC, or
a public use PC. For public use PCs, you must trust the place your at just
as you trust an ATM machine that you walk up to. Just as fake ATM's can suck

out your info, a fake validator can suck your credit card and pin number,
and private key. My rationale: Any public use PC will be a security risk,
forever. This does not apply to my design, but to everything. The goal is to
be practical, not theoretically unbreakable.

End user: that's you.

universal-id.net: the central authentication network. When you setup an
account, a figure 63 record is created. Your first account has a sub id #
of 00 (value 63050). Your next one will be 01. It stops at 99. So you can
have 100 accounts per credit card. Note that your credit card # is stored in
an incomplete manner (value 63005). The expiration date is not stored. To
compute the rest of the credit card, a brute force method is needed. The
fact that the completion password (reference unid id design) is not fixed in
length works to your advantage. Note that nothing keeps the incomplete
credit card number from being shorter, thus storing less of it. When this
happens, the beginning of the UNI ID pin grows in length.

How it works:
Note from the design, the UNI ID pin # (the 1st of the 3 passwords) begins
with 4 numbers, which are assigned to you. Only the last part of the pin
number is your chosen "completion" password. Thus, if the last 2 digits of
my credit card number are 34, and this is my first UNI ID (sub account
number is 00), and my chosen completion password is "ok", then my pin number
is "3400ok" Ideally, a person will use a longer password than ok. The fact
that the completion password is not fixed in length, but the ID is, helps to
hide the info behind the hash function, and utilize its 1-way property to
make computation of the info a pain in the ass.

At this point in time, only you have your uni id pin number. The central
system has your incomplete credit card number and uni id on file. (and your
RSA public key, but not private key)

Here's how the authentication steps go. Follow fig 96.
You either manually enter your credit card number and expiration date, or
swipe the card thru the keyboard. You manually enter your pin number. Think
of this step as your login name and password, for a global file system
login.

The validator computes your uni id by hashing your full credit card number
and your uni id password (less the first 2 digits, since the credit card
number is complete).

The validator sends to universal-id.net "I'm validating uni id X" along with
a timestamp.

universal-id.net receives this request, looks up the ID's dbase record by
searching value 63003 (fig 63). It then prepares an IPsec tunnel (IPsec
could be substituted for encryption, I suppose) using a hash of the first 8
digits of the credit card number & time stamp as the key. This is done by
referencing value 63005 to get the (incomplete) credit card number.

During this time, the validator will have also prepared an IPsec channel,
using the same info. Note that the only info that has crossed the internet
is the ID (the biglongrandomstring AT universal-id.net).

Because both sides prepare the IPsec channel identically, and key it with
the same password (hash of credit card and timestamp), they will
communicate.

Universal-id.net then sends an ok message, via the IPsec. The validator
sends the uni id pin number to universal-id.net via IPsec. The incomplete
credit card number (value 63005) is appended with the newly received pin
number. It is then hashed, and compared to value 63003. If it matches, the
credit card is charged 15 cents (or whatever), and the item on the credit
card is the uni id, and the timestamp. Thus they will have an audit log for
their authentication. This step is what identifies the person as being that
dbase record. Assuming the pin number is kept secret, and the credit card
charge goes thru, they are considered authenticated.

Now, a number of things can go wrong. The IPsec can be keyed differently,
the pin number and credit card may hash to a different or non existent id,
the credit card charge may fail. All of these events represent a failed
authentication.

That's the essence of it. Note that fig 96 is the only figure that
represents the xfer of the pin number via IPsec, I have yet to update the
other uni id figures.

Now, I haven't answered everything, but give me issues that you want more
detail on, and I'll gladly elaborate.

I think this is unique because either nobody has thought of it before, or
it wont work because there's something that I'm missing.

Either way, that's why I'm here.

-----Original Message-----
From: steve jenson [mailto:stevej AT sieve.net]
Sent: Saturday, August 11, 2001 3:27 PM
To: Global-Scale Distributed Storage Systems
Subject: Re: freenet

Quoting Josh (josh AT mercuryfs.net):

> It is true that credit card fraud does make a lot of money. My goal is a
> global method whereby a person does not need to be assigned another ID to
> remember. I figured that since credit cards are global, I can utilize
them.
> Visa and Mastercard currently are not deployed in China, but they are
> virtually everywhere else. Since our charges will be 25 cents or less, any
> abuse should show up easily.
>
> Even though its going to be a virtually open source design, we will
probably
> keep the credit card module closed source, so people cant modify it and
> redistribute it in order to steal credit card numbers. This should help
with
> that issue.

For about 5 minutes until somebody reverse engineers your code. If
keeping your source closed on this is your measure of protection then
you're in deep trouble. There's no security through obscurity.



> We believe that the business model of charging an end user an
> insignificant amount in order to authenticate them, is a valid model. An
> added byproduct of using a credit card is that the bill is an audit log.
>
> Technically, the credit card number is not ever stored locally, and its
not
> transferred across the internet in an unprotected form. Basically, a UNI
ID
> is a hash of a credit card number and password. To see this, click here


> www.mercuryfs.net/design/uni_id.pdf

First, why are you making people download PDF's and shockwave files when
regulare HTML and animated gif's would suffice?

>From uni_id.pdf
>A UNI ID is a globally unique identification, in the form of an
>email address. Example: bigassunreadblestring AT universal-id.net

I thought you just said that you weren't going to be giving people another
ID number to remember?

"no two people have the same card number"

I think this was already pointed out to be not true.


"When a credit card is invalidated, its UNI IDs no longer test valid"

I would appreciate you going into depth regarding exactly how you generate
the ID from the Credit Card number and Pin in such a way as to make it
easily
provable to be invalid without central ID repository lookups. Banks already
know that central lookups for every transaction will not scale. (Refer to
Ross Anderson's excellent 'Security Engineering' chapter 9)


"When a user sets up a UNID ID account, 3 passwords are given."

You get an F- in usability, son.


"4. The party wishing to validate your ID will have just received either
VALID or INVALID."

ooh!! I get all sorts of excited when I read about authentication schemes
that never hand back a token that can be guaranteed to prove the end state
of the transaction. If you don't know why, that doesn't surprise me.


(skipping ahead.. getting bored with techno-babble):

"User and Server types operate the same, but Groups rely on
universal-id.net
to be the trusted source of the private key

When a member requests a groups private key..."

huh? Do you know anything at all about public key cryptography?


"When you login to a PC connected to the Internet and slide your credit
card thru (sic) your keyboad (will soon be a standard)"

This is just stupid. Nobody will do this.


Well, I could do this all day long but I think I'd rather go work on a
useful project.


> Our goal will be to engineer the system to a near foolproof and automated
> level.


Ah yes, who doesn't have this goal?

> ... ... ...Personally, I blame Hollywood. I think they turned
> most of the women around here into stuck-up bitches.

This sentece tells me that you should work more on your lady skills and
less on thinking up vapourware.


cheers,
steve


--
steve jenson <stevej AT sieve.net> http://sieve.net/
PGP fingerprint: 79D0 4836 11E4 A43A 0179 FC97 3AE2 008E 1E57 6138

---
You are currently subscribed to bluesky as: josh AT mercuryfs.net
For list information visit http://www.transarc.ibm.com/~ota/bluesky/





  • uni id, Josh, 08/02/2001
    • <Possible follow-up(s)>
    • uni id, Josh, 08/03/2001
    • uni id, Josh, 08/11/2001

Archive powered by MHonArc 2.6.24.

Top of Page