Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)

[McMeikan, Andrew]

> The original issue involves three factor authentication
> 
> * something you have
stealable perhaps
> * something you know
most people are careless with secrets
> * something you are
This is the real bit, how tied to identity can it be bound.  How tightly do
people want to be bound.  In any abuse or failing of identity whatever that
identity was authorized for is going to be the *Responsibility* of the true
identity.  I frequently give out my true name (there it is at the top :)
perhaps there are times I specifically do not.

I mention this not to be difficult just to mention that the responsibility
side has not really been discussed much yet is the real driving factor for
privacy and security in the first place.  Identity theft today, as annoying
as it is could be much worse once everyone accepts a system as infallible.
Potentially a fake digital signature could be explained away as due to
keyboard loggers and trojans today.  That sort of excuse? will be a lot
harder to believe once some of the key is embedded within your skull or
body.  It will become implicitly non-repudiatable (however society
interprets that).

If the something you are is a picture on a blurred dirty screen barely
glanced at by a bored worker with a full que it will mean very little.  I
would love to see some alternative implant chips yet don't believe the
popular choices are up to it (DNA,retina, thumb print)

> 
> A public key can be representative of  hardware token ... say 
> a token where 
> the private key is generated on the token and is designed to 
> never leave 
How can this be verified by the person who will become Responsible for the
actions of this key, how can it be verified that the key has been generated
in a secure way?  These are non-trivial for the designer and I would suggest
that in the scenario where the designer, manufacturer and government are on
a slightly greener side of the fence (economically) than the user it would
be infeasible to know its safety.


> The issue is that can the validating of the entity in 
> possession of the 
> token be a separate business process issue from validating 
> the integrity of 
> the hardware token. The idea is that the integrity of the 
> hardware token 
> can be treated as a totally separate business process from 
> the process of 
> validating the entity being enrolled (an entity that happens 
> to possess the 
> hardware token).
> 
> Treating them as totally separate business process doesn't preclude 
> collapsing the enrolling of the entity and enrolling the 
> hardware token 
> into a single process. However, not treating them as separate 
> business 
> process will pretty much preclude ever being able to treat 
> them as separate 
> processes.

Call me pessimistic but I see collusion as inevitable.  My only hope would
be that lots of independent people start making these things.  If people
want them certified that will be an opportunity for free market to work.
People paranoid about deliberate backdoors would build their own, people
worried about the key being sniffed electrically will get one certified low
emitting, those who trust the government or their favourite trans national
corporation will buy (or get issued with one) from them.

 
> So the question is as part of the enrolling process, can the 
> integrity of 
> the hardware token be treated as a totally separate business 
> issue from the 
> characteristics of the entity in possession of the hardware 
> token, say like 

I should hope so yes.  In a free world it certainly should, while separate
there is the hope that such a token is in the best interest of its user.  If
the signature is to mean anything and can not be repudiated then its
authorized user is highly motivated to keep its private key contents
private, sharing such ability to sign would be the equivalent of power of
attorney (IANAL)


> entity. What 
> would be the incremental requirement for adding being able to 
> enroll (& 
> trust) the integrity of a consumer presented hardware token.

Is there a need for the identity verifying authority to trust the presented
token?  If a person satisfies the authority as to their identity and gets a
'stamp' to say the holder is really this person then it is only to that
persons detriment if they give it away.

> 
> So, i'm a little bit biased, I claimed that I ruthlessly 
> discarded all 
> feature and function from AADS chip strawman that wasn't 
> needed for trusted 
> authentication
> http://www.garlic.com/~lynn/index.html#aadsstraw
> 
> complexity can contribute to insecurity ... KISS and focus 
> can contribute 
> to security.

A fence adds both complexity and security, add barbed wire and you get more
of both.

Wish list.
Token small and handheld, smart card sized with IR, keypad and large display
area ;)
private keys can go in but not out.
can exchange public keys.

I am torn about rfid chips to aid the who you are.  The only place that is
truly private is inside the mind and as technology advances even that may
not hold.  Would I implant a chip to enable a key to be decrypted by a pin
only when in my hand?  No.  But I'd probably feel more secure if I had to
touch a separate id device to my token before it could sign.

When you consider how much leverage a false signature could have over your
life if it was considered fully binding then I would only sign with a key
loosely bound to my identity.  A key for spending within a credit limit, a
key for signing non-contractual letters.  A key for voting?

But I would not want a key for signing confessions of guilt.  I could never
trust that it could not be stolen.


	cya,	Andrew...

PS: strangely this message is not cryptographically signed, any evidence
pointing to who wrote this is purely circumstantial, yet would probably
still suffice to lock me up if its contents were illegal.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com