Re: Using TCPA

2005-02-05 Thread 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 th

Re: Any TLS server key compromises?

2004-08-14 Thread 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

Re: dual-use digital signature vulnerability

2004-07-28 Thread 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

Re: dual-use digital signature vulnerability

2004-07-18 Thread 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-u

Re: dual-use digital signature vulnerability

2004-07-18 Thread 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 sam

Re: PKI Research Workshop '04, CFP

2003-10-22 Thread 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 aut

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 att

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

2003-09-11 Thread 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

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

2003-09-10 Thread 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 exp

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 ther

fyi: bear/enforcer open-source TCPA project

2003-09-08 Thread 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

Re: blackmail / real world stego use

2003-08-27 Thread 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

Re: [Fwd: BugTraq - how to coverup the security]

2003-07-16 Thread 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

Re: [Fwd: BugTraq - how to coverup the security]

2003-07-15 Thread 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 distin

Re: [Fwd: BugTraq - how to coverup the security]

2003-07-14 Thread 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 s

Re: An attack on paypal --> secure UI for browsers

2003-06-09 Thread 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