Re: fyi: bear/enforcer open-source TCPA project

2003-09-11 Thread Rich Salz
 You propose to put a key into a physical device and give it
 to the public, and expect that they will never recover
 the key from it?  Seems unwise.

You think the public can crack FIPS devices?  This is mass-market, not
govt-level attackers.

Second, if the key's in hardware you *know* it's been stolen.  You don't
know that for software.
/r$
--
Rich Salz  Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: fyi: bear/enforcer open-source TCPA project

2003-09-11 Thread Peter Gutmann
Rich Salz [EMAIL PROTECTED] writes:

Second, if the key's in hardware you *know* it's been stolen.  You don't know
that for software.

Only for some definitions of stolen.  A key held in a smart card that does
absolutely everything the untrusted PC it's connected to tells it to is only
marginally more secure than a key held in software on said PC, even though you
can only steal one of the two without physical access.  To put it another way,
a lot of the time you don't need to actually steal a key to cause damage - it
doesn't matter whether a fraudulent withdrawal is signed on my PC with a
stolen key or on your PC with a smart card controlled by a trojan horse, all
that matters is that the transaction is signed somewhere.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: fyi: bear/enforcer open-source TCPA project

2003-09-11 Thread Scott Guthery
There are roughly 1B GSM/3GPP/3GPP2 
SIMs in daily use and the number of 
keys extracted from them is diminishingly 
small.

-Original Message-
From: bear [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2003 3:43 AM
To: Sean Smith
Cc: [EMAIL PROTECTED]
Subject: Re: fyi: bear/enforcer open-source TCPA project 




On Wed, 10 Sep 2003, Sean Smith wrote:


 So this doesn't
 work unless you put a speed limit on CPU's, and that's ridiculous.

Go read about the 4758.  CPU speed won't help unless
you can crack 2048-bit RSA, or figure out a way around
the physical security, or find a flaw in the application.

You propose to put a key into a physical device and give it
to the public, and expect that they will never recover
the key from it?  Seems unwise.

Bear

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: fyi: bear/enforcer open-source TCPA project

2003-09-11 Thread Damian Gerow
Thus spake Rich Salz ([EMAIL PROTECTED]) [11/09/03 08:51]:
  You propose to put a key into a physical device and give it
  to the public, and expect that they will never recover
  the key from it?  Seems unwise.
 
 You think the public can crack FIPS devices?  This is mass-market, not
 govt-level attackers.

And 'the public' doesn't include people like government level attackers?
People like cryptography experts?  People who like to play with things like
this?

'The public' only includes the sheeple, and nobody else?

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


is secure hardware worth it? (Was: Re: fyi: bear/enforcer open-source TCPA project)

2003-09-11 Thread Sean Smith

Just to clarify... 

I'm NOT saying that any particular piece of secure hardware can never be
broken.   Steve Weingart (the hw security guy for the 4758) used to insist that
there was no such thing as tamper-proof. On the HW level, all you can do is
talk about what defenses you tried, what attacks you anticipated, and what
tests you tried.

What I am saying is that using secure coprocessors---defined loosely, to
encompass this entire family of tokens---can be a useful tool.  Whether one
should use this tool in any given context depends on the context. Are there
better alternatives that don't require the assumption of physical security?
How much flexibility and efficiency do you sacrifice if you go with one of
these alternatives? How dedicated is the adversary?  What happens if a few
boxes get opened?  How much money do you want pay for a device?

Some cases in point: it's not too hard to find folks who've chosen
a fairly weak point on the physical security/cost tradeoff, but still
somehow manage to make a profit.  

Of course his all still leaves unaddressed the fun research questions of how to
build effective coprocessors, and how to design and build applications that
successfully exploit this security foundation.  (Which is some of what I've
been looking into the last few years.)


--Sean

-- 
Sean W. Smith, Ph.D. [EMAIL PROTECTED]   
http://www.cs.dartmouth.edu/~sws/   (has ssl link to pgp key)
Department of Computer Science, Dartmouth College, Hanover NH USA




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: fyi: bear/enforcer open-source TCPA project

2003-09-11 Thread Rich Salz
And 'the public' doesn't include people like government level attackers?
People like cryptography experts?  People who like to play with things like
this?
No it doesn't.  *It's not in the threat model.*

	/r$

--
Rich Salz, Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: fyi: bear/enforcer open-source TCPA project

2003-09-09 Thread Sean Smith
 
 How can you verify that a remote computer is the real thing, doing
 the right thing?
 
 You cannot.

Using a high-end secure coprocessor (such as the 4758, but not
with a flawed application) will raise the threshold for the adversary
significantly.

No, there are no absolutes.  But there are things you can do.
 
 The correct security approach is to never give a remote machine
 any data that you don't want an untrusted machine to have. 

So you never buy anything online, or use a medical facility
that uses computers?





-- 
Sean W. Smith, Ph.D. [EMAIL PROTECTED]   
http://www.cs.dartmouth.edu/~sws/   (has ssl link to pgp key)
Department of Computer Science, Dartmouth College, Hanover NH USA




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]