Subject: [pkix] Secure Credential Cloning

From: Anders Rundgren <[email-masked]>
Date: Fri, 22 Jul 2011 22:23:36 +0200

This posting is just an attempt keeping patent trolls away.
The described concept is already in production use (in various
variants), but hasn't been *publicly* documented AFAIK.

Secure Credential Cloning
=========================

There are quite a bunch of efforts based on having credentials in the cloud
as well as "syncing" them to various devices.  This fits a certain category
of credentials.  However, banks, governments, and enterprises are unlikely
to buy into this concept for various rational and historical reasons.

FWIW, the SKS/KeyGen2 scheme addresses credential mobility/accessibility
in two different ways:

- Through physical means (if using USB token form factor)
- Through credential "cloning"

Cloning is not to be confused with copying; it is a process when you
get another *instance* of the same credential.  Assume that you have a
government- or bank-credential (presumably in an awkward container
of their choice such as a regular smart card...), and that you would
rather use your "iPhone" as credential carrier.

If the issuer accepts your choice of credential carrier (typically
listed on the issuer's site), you may login to the issuer using the
original credential and get a new one for the target device.
How can this be performed in a secure manner you may wonder?

1. The device has a device certificate which identifies the brand and
   ID to the issuer during the issuance process

2. During enroll the user specifies the SHA1 (or similar) of the device
   certificate so that the issuer is assured that it is talking to the
   right container

Note: no enrollment passwords are needed!

A further advantage with cloning is that in case you lose a credential
it can be revoked while other instances of it are still usable making
it a sort of a credential backup solution as well.

Anders Rundgren
http://webpki.org/auth-token-4-the-cloud.html

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 22 Jul 2011 17:24:47 -0400

WARNING: contains banned part

Subject: RE: [pkix] Secure Credential Cloning
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Date: Fri, 22 Jul 2011 17:24:47 -0400

I suppose an abundance of caution is warranted, given the number of
dubious patents already issued, but isn't a method supposed to be
non-obvious in order to be patentable?

You are requesting issuance of a credential, using the subject's
credential to authenticate the request.  Is there anything novel about
that idea?  The new credential is NOT a clone; some fields MUST be
different (serial number, validity, subject public key, signature), some
fields MAY be different (issuer, extensions such as certificate policy
and key usage), but presumably in your use case the subject DN and the
subject alternative name extension MUST be copied from the
authenticating cert to the new cert.

If there are no other mechanisms used to authenticate the requestor, the
assurance of the new credential will be less than the original.  That is
the same problem as with paper "breeder" credentials - if you can get
the DMV to renew a forged/stolen driver's license, or get some other
issuer to give you a new credential based on the license, then you have
a way of bootstrapping a dodgy credential into a perfectly legitimate
one.  I wouldn't want a hacker to be able to misuse my smart card to get
their cellphone provisioned with a legitimate credential containing my
name, so the issuance method should have other safeguards.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Anders Rundgren
Sent: Friday, July 22, 2011 4:24 PM
To: [email-masked]
Subject: [pkix] Secure Credential Cloning

There are quite a bunch of efforts based on having credentials in the
cloud
as well as "syncing" them to various devices.  This fits a certain
category
of credentials.  However, banks, governments, and enterprises are
unlikely
to buy into this concept for various rational and historical reasons.

Anders Rundgren
http://webpki.org/auth-token-4-the-cloud.html
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 23 Jul 2011 08:34:16 +0200

> non-obvious in order to be patentable?

Yes, that was the original idea but is has been proven over and over
that it doesn't work in practice for software methods.

> that idea?

Not really, it is rather the use of a strong credential to get a
a strong "clone" and the mechanics to do it (including two-way
usage of device IDs) that may be novel from a patent troll's
perspective.

> The new credential is NOT a clone; some fields MUST be

What a "clone" is in a biological sense is pretty clear.  It has the
same DNA but not the same flesh and blood.  I just felt that the
word "clone" was a bit cool and not entirely wrong either.

I guess you would prefer "derived"?

For the end-user it is rather a "copy" :-)

How you distinguish a "cloned/derived/copied" credential from
the original is outside this specification but would in the
simplest [PKI] case only be the serial number and validity plus
the fact that the public key would be different.

> assurance of the new credential will be less than the original.

You mean that the assurance gets "diluted" by each "cloning"?

> That is the same problem as with paper "breeder" credentials - if you can get
> one.

I believe there is a difference here; in this case the issuer is meant
to be *identical* so having one or multiple stolen credentials should
not make a big difference unless the identify thief is working with
some kind of coordinated multi-lane attack on a user's assets.

> I wouldn't want a hacker to be able to misuse my smart card to get

There are of course an infinite number of things you could add during
enrollment to mitigate this.  The specification only deals with the
technical part of the "cloning" and leaves policy to the deployers.
Each trust-network will apply their own ideas and policies.

>From your DoD watchtower the following claim could be noteworthy:
I believe that this is a more likely candidate for future mobile
government solutions than connecting external CAC cards to a device.

A rudimentary predecessor to this scheme has already been put in
production by at least one big government agency.   Yes, yours
truly designed the system for them :-)

Anders