Re: Using TCPA
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?
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
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
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: dual-use digital signature vulnerability
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: PKI Research Workshop '04, CFP
(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)
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
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
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 http://www.research.ibm.com/gsal/tcpa/.) For more information on our project, see Dartmouth College Technical Report TR2003-471 available from http://www.cs.dartmouth.edu/~sws/abstracts/msmw03.shtml 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]
