Re: Using TCPA

[Sean Smith]

On Feb 4, 2005, at 6:58 AM, Eric Murray wrote:
So a question for the TCPA proponents (or opponents):
how would I do that using TCPA?

check out
enforcer.sourceforge.net
We also had a paper at ACSAC 2004 with some of the apps we've built on 
it.

Two things we've built that haven't made it yet to the sourceforge site:
- an SELinux version
- an OpenSSL engine
--Sean

Sean W. Smith  [EMAIL PROTECTED]  www.cs.dartmouth.edu/~sws/
Hanover, NH USA  (Where the Appalachian Trail crosses the VT-NH border)
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Any TLS server key compromises?

[Sean Smith]

has a TLS server (or client, for that matter) key ever actually been 
compromised?

Hi, Marc!
I don't know about in-the-wild attacks.
However, proof-of-concept attacks:
Server-side: Brumley and Boneh did timing attacks on Apache SSL 
servers---see their Usenix Security paper from 2003.

Client-side: we've done a number of host-based attacks and http-based 
attacks, to steal or borrow use of a user's client-side SSL/TLS key.  
See:

 J. Marchesini, S.W. Smith, M.Zhao.
"Keyjacking: The Surprising Insecurity of Client-side SSL"
Computers and Security.  To appear, 2004.
http://www.cs.dartmouth.edu/~sws/abstracts/msz04.shtml
--Sean
Sean W. Smith [EMAIL PROTECTED]  www.cs.dartmouth.edu/~sws/
 Asst Prof, Department of Computer Science, Dartmouth College.
 Director, Cybersecurity and Trust Research Center, Institute for 
Security Technology Studies.

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

Re: dual-use digital signature vulnerability

[Sean Smith]

For what it's worth, last week, I had the chance to eat dinner with 
Carlisle Adams (author of the PoP RFC), and he commented that he didn't 
know of any CA that did PoP any other way than have the client sign 
part of a CRM.

Clearly, this seems to contradict Peter's experience.
I'd REALLY love to see some real numbers here---how many CAs (over how 
many users) do PoP a sane way; how many do it a silly way;  what 
applications people use their keys for, etc.

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

Re: dual-use digital signature vulnerability

[Sean Smith]

it isn't sufficient that you show there is some specific 
authentication protocol with unread, random data ... that has 
countermeasures against a dual-use attack ... but you have to 
exhaustively show that the private key has never, ever signed any 
unread random data that failed to contain dual-use countermeasure 
attack.

Why isn't it sufficient?   (Quick: when was the last time anyone on 
this list authenticated by signing unread random data?)

The way the industry is going, user keypairs live in a desktop 
keystore, and are used for very few applications.  I'd bet the vast 
majority of usages are client-side SSL, signing, and encryption.

If this de facto universal usage suite contains exactly one 
authentication protocol that has a built-in countermeasure, then when 
this becomes solid, we're done.

Our energy would be better spent on the real weaknesses: such as the 
ease of getting desktops to just cough up the private key, or to use it 
for client-side SSL without ever informing the user.

And on the real problems: such as using the standard suite to get the 
trust assertions to match the way that trust really flows in the real 
world.

--Sean








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

Re: dual-use digital signature vulnerability

[Sean Smith]

at the NIST PKI workshop a couple months ago  there were a number
of infrastructure presentations where various entities in the
infrastructure were ...signing random data as part of authentication 
protocol

I believe our paper may have been one of those that Lynn objected to.  
We used the same key for client-side TLS as well as for signing a 
delegation certificate.  However (as we made sure to clarify in the 
revised paper for the final proceedings):

In SSL and TLS, the client isn't signing random data provided by the 
adversary.  Rather, the client is signing a value derived from data 
both the client and server provide as part of the handshake.  I do not 
believe it is feasible for a malicious server to choose its nonces so 
that the resulting signature be coincide with a valid signature on a 
delegation cert the client might have constructed.

(On the other hand, if we're wrong, I'm sure that will be pointed out 
repeatedly here in the next day or two :)

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

Re: PKI Research Workshop '04, CFP

[Sean Smith]

>(To those people who missed the original comment a year or two back, the first
> PKI workshop required that people use plain passwords for the web-based
> submission system due to the lack of a PKI to handle the task).

Hey, but at least the password was protected by an SSL channel,
which was authenticated by a real certificate signed by one of
the 10^4 trust roots built into your browser :)

---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]

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

[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

[Sean Smith]

>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?

It's been on the market for six years now; so far, the foundation
has held up.(We also were darn careful about the design
and evaluation; we ended up earning the first FIPS 140-1 Level 4
cert, but went beyond it in several respects.)

But there are numerous war stories and drawbacks---which is
why I find the new generation of initiatives interesting.
(Particularly since I don't have to build products anymore! :)

> Seems unwise

As does the alternative proposition that one should NEVER, under any 
circumstances, have sensitive data or computation on a remote machine.

--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

[Sean Smith]

> 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.


> Yes.  Protocol designers have been explaining how to do them for
> decades.  

But (at a high-level) there are things that are awkward
or extremely impractical to do with, say, multi-party computation.

That's where the "secure hardware" work---from Abyss, to TCPA, to
plastic-speckles, to the CPU+ work at MIT and Princeton---comes in.  



--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

[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]

fyi: bear/enforcer open-source TCPA project

[Sean Smith]

The Bear/Enforcer Project
Dartmouth College

http://enforcer.sourceforge.net
http://www.cs.dartmouth.edu/~sws/abstracts/msmw03.shtml

How can you verify that a remote computer is the "real thing, doing
the right thing?"  High-end secure coprocessors are expensive and
computationally limited; lower-end desktop enhancements like TCPA and
the former Palladium have been mainly limited to Windows and
proprietary development.

In contrast, this code is part of our ongoing effort to use open
source and TCPA to turn ordinary computers into "virtual" secure
coprocessors---more powerful but less secure than their high-assurance
cousins.

Our current alpha release includes the Linux Enforcer Module, a TCPA
enabled LILO, and a user-level TCPA library.  All source is available
from the SourceForge site.

The Linux Enforcer Module is a Linux Security Module designed to help
improve integrity of a computer running Linux.  The Enforcer provides a
subset of Tripwire-like functionality.  It runs continuously and as
each protected file is opened its SHA1 is calculated and compared to a
previously stored value.

The Enforcer is designed to integrate with TCPA hardware to provide a
secure boot when booted with a TCPA enabled boot loader.  TCPA
hardware can protect secrets and other sensitive data (for example,
the secrets for an encrypted loopback file system) and bind those
secrets to specific software.

When the Enforcer detects a modified file it can, on a per-file basis,
do any combination of the following: deny access to that file, write an
entry in the system log, panic the system, or lock the TCPA hardware.
If the TCPA hardware is locked then a reboot with a un-hacked system is
required to obtain access to the protected secret.

We developed our own TCPA support library concurrently with, but
independently from, IBM's recently announced TCPA library.  Our library
was an initial component of the Enforcer project.  However, our
in-kernel TCPA support and the enforcer-seal tool are derived from
IBM's TCPA code because of its ease of adaptation for in-kernel use.
We plan to use our more complete library for user-level applications.
(IBM's TCPA code and documentation is available from
.)

For more information on our project, see Dartmouth College Technical
Report TR2003-471 available from


Or contact Omen Wild at the Dartmouth PKI Lab: 
Omen Wild <[EMAIL PROTECTED]>



-- 
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: blackmail / real world stego use

[Sean Smith]

>A guy in Google can do it.

Check out:

Using caching for browsing anonymity 
Anna M. Shubina, Sean W. Smith 
Dartmouth TR2003-470 
http://www.cs.dartmouth.edu/reports/abstracts/TR2003-470/

The code's available for download, too.












-- 
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: [Fwd: BugTraq - how to coverup the security]

[Sean Smith]

> I apologise for the snippety email last night,

no problem!

> That is significant!  Was this code not
> folded back into Mozilla?

No, unfortunately.

According to Eileen (who was the lead on this),
it didn't easily fit into things:
- it was not clearly a "bug fix"
- it touched many modules (so it wasn't clear who would own it)
- it changed the UI in a way that some folks weren't happy with

--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: [Fwd: BugTraq - how to coverup the security]

[Sean Smith]

> > Are other platforms more secure or do they just receive
> > less scrutiny?  Or is it that Microsoft does not react quickly to
> > found bugs? .

My point was just that the browser paradigm was not really designed with the
idea of making the security status information always clearly distinguishable
from the content provided by malicious servers.

In our project, we'd looked at popular browser/OS combinations (two years ago),
and found that (with some cleverness) you could produce fairly convincing
impersonations in many scenarios. The barriers were repeatedly permeable. E.g.,
does the browser mark your popup window with a label that spoils the spoof? No
problem: just send an image of the window instead.

As has been mentioned on this list before, we also designed and implemented a
trusted path solution in Mozilla. (But this was complicated by the fact that
each new release of Mozilla seemed to break our code :)

> The question at hand is this:  if secure browsing
> is meant to be secure, but the security is so easy
> to bypass, why are we bothering to secure it?
> 
> Or, if we should bother to secure it, shouldn't
> we mandate the security model as applying to the
> browser as well?

Exactly.

That was the whole point of our Usenix paper last year

E. Ye, S.W. Smith.
``Trusted Paths for Browsers.''
11th Usenix Security Symposium. August 2002 
http://www.cs.dartmouth.edu/~sws/papers/usenix02.pdf

---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: [Fwd: BugTraq - how to coverup the security]

[Sean Smith]

Does this really surprise anyone?  

When I had some students try this out (providing content
that browsers render in a way that makes it look like security 
info from the browser) a few years ago, there was just no end
to the tricks one could play...

If you don't design a trusted path into the system, why should
you expect there to be one?

--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: An attack on paypal --> secure UI for browsers

[Sean Smith]

>Yuan, Ye and Smith, Trusted Path for Browsers, 11th Usenix security symp, 
>2002.

Minor nit: just Ye and Smith. (Yuan had helped with some of the spoofing)

Advertisement: we also built this into Mozilla, for Linux and Windows.
http://www.cs.dartmouth.edu/~pkilab/demos/countermeasures/


--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]