Re: Identifiers on ID Cards

[jack suess <jack () UMBC EDU>]

We are going through this process now bringing up a new ID card system.

It is hard to convince people you don't want id's associated with
data in your systems on the card because it is so easy to get batch
feeds and this information is somewhat static -- but you really
don't. We had to show people that if you put infomation on the
magstripe tightly tied to a user it is a security risk. Magstripe
writers are pretty cheap. Getting blank cards is easy. If you have
some identifier on the magstripe associated with a system then people
who can get access to that data in the system could potentially
create fake cards. With those cards they have access to facilities or
access to funds on the one-card.

Worse, to meet davids point of revocation of the id card, what is
common practice in the industry is to use a base identifier and then
add two digits for the issue level. If you lose the card you
increment the issue level by 1. Of course, if the card is stolen it
is simple to reproduce the "reissued" card because you know they will
just increase the issue level by one.

We're going with essentially a throw-away ISO identifier that is not
tied to any system. The user won't even know (or need to know) what
the number is on their card. If they lose it they will get a new card
with a new number.

The challenge in doing this is you have to have an identity
management system in place that can handle the mapping. You also have
to build in some integration between the card system and other
systems using the card. When someone loses their card you reissue a
new card and then push out the new identifier on the magstripe to the
other security systems using the card, in our case we have lenel. The
downside with this is it adds more work to central IT and most people
don't recognize the benefits that come from this.



jack suess



On Dec 16, 2005, at 2:44 PM, David L. Wasley wrote:

> Well, if you're going to reissue a credential with the same
> identifier, you will require some way to invalidate the prior,
> stolen credential.  PKI offers that function but it also requires
> some infrastructure to support checking.  :-/
>
> When I was working on this, I felt that no identifier issued for
> another purpose should be used, e.g. SSN or student ID or email
> address.  It creates an interdependency between two functions that
> could cause problems if it is necessary to change the binding
> between that identifier and the physical person.  Instead, I
> proposed "a unique (integer or string) identifier that would link
> to a database entry for the subject and never be re-issued to a
> different physical person."  That identifier need never change
> unless it becomes compromised.  Meanwhile, every other piece of
> information about the subject could change and the credential would
> still be valid.
>
> If the identifier were to become compromised, e.g. the credential
> containing it was stolen or lost, a new identifier could be created
> for that physical person, pointing to the same data, and a new
> credential issued.  (Of course, with PKI one could simply
> invalidate the old credential and reissue one with the same
> identifier ;-) )
>
>         David
>
> -----
> At 9:19 AM -0800 on 12/16/05, Karen Eft wrote:
>
> > Dave,
> > I'm not aware of existing policy here on this point, but I really
> > like your
> > suggested principle of "encoding with an identifier that is re-
> > issuable".
> >
> > If I confirm that this is not already included in our policy/
> > guidelines
> > somewhere, I'm going to see about adding it.
> > --Karen
> >
> > On Dec 15, 2005, at 11:46 AM, Dave Huth wrote:
> >
> > > I'm wanting to learn more about best practices associated with what
> > > type of identifiers to encode on ID Cards.  There doesn't seem to
> > > be anything in the list archives on this subject - does anyone have
> > > any good references.
> > >
> > > The types of questions surround the apporpriate type of identifier
> > > to encode.  For instance is it a wise move to encode things like
> > > Student/Employee ID, Login ID, and those types of identifiers that
> > > are very difficult to change/re-issue; or should the Card be encoded
> > > with an identifier that is re-issueable if the card is lost/stolen
> > > and let a directory link that identifier with an individuals
> > > collection of identity data?
> > >
> > > Thanks,
> > >
> > > Dave Huth
> > > University of Utah
> > ======================================================
> >   Karen E. Eft   Information Technology Policy Manager
> >   UC Berkeley (510)642-4095 http://itpolicy.berkeley.edu
> >  ======================================================