Re: Free Rootkit with Every New Intel Machine
Peter Gutmann wrote: Ian Farquhar (ifarquha) [EMAIL PROTECTED] writes: For example: the Gigabyte GA-965QM-DS2 (rev 2.0) which features security enhancement by TPM. More common (ASUS, Foxconn) was the TPM Connector, which seemed to be a hedged bet, by replacing the cost of the TPM chip with the cost of a socket. Those are actually misleading, since there's no certainty that you'll be able to find anything that'll actually plug into them. That is, not only are the TPM whatever-they-are-that-goes-there's almost impossible to find, but if you do find one there's no guarantee that it'll actually work when plugged into the header. In practice this is just a way of adding the TPM keyword to your marketing without having to actually do anything except include a dummy header on the MB. There are third party TPM modules, which could allow some degree of standardization: http://www.ieiworld.com/en/news_content.asp?id=erbium/projectOBJ00244201news_cate=Newsnews_sub_cate=Product The IEI TPM module is used in their own motherboards and some VIA motherboards. They actively market the pluggable modules. Thinkpads appear to use a different connector: https://www.cosic.esat.kuleuven.be/publications/article-591.pdf 30 pins instead of 20 pins. The Low Pin Count bus is an ISA bus replacement is specified as the TPM interface, and isn't defined for connector use, so a connector pin out isn't standardized. http://www.intel.com/design/chipsets/industry/25128901.pdf (the spec) (For people who don't work with the innards of PCs much, most motherboards have assorted unused headers, sites for non-installed ICs, and so on, as a standard part of the MB. The TPM header is just another one). Peter. In addition to pluggable modules, TPM can also be an assembly bill of materials option, where you have a chip and a few passive components not stuffed for non-enterprise PCs or notebooks. The advantage of a pluggable module would be to allow late binding build configurations when you can't adequately forecast demands. Even the low costs of TPM hardware, patent licenses, BIOS licenses, etc., are probably enough to prevent blanket inclusion in personal computers not intended for enterprise use today. TPM can also be built into chip sets like Intels Bearlake, which removes the hardware cost. TPM may well end up being present ubiquitously. One of the driving forces for TPM adoption going forward will be enterprise remote or distributed management. http://www.dmtf.org/home Doing distributed management with TPM allows some degree of security that would otherwise be missing. Distributed management is the purpose of Intels vPro and iAMT initiatives. Note that the distributed management push is relatively recent, going mainline in the last year or so and may signal an upcoming acceleration in TPM adoption. Also of note is that the membership list for the Distributed Management Task Force contains most of the big name PC sellers. Distributed management can be OS 'gnostic, the driving need is the ability to handle large volumes of software updates and security patches. While some OS's require large volumes of security patches, others are evolving fast enough to require automated updates. We're pretty much guaranteed to see see enterprise adoption across all platforms. Linux supports TPM devices directly, as will Solaris. Apple (mis)uses TPM to unsuccessfully prevent OS X from running on non-Apple Hardware. All Apple on Intel machines have TPM, that's what 6 percent of new PCs? There is a virtual TPM in Xen, IBM would tell you that you can't operate a trusted computer with out a security server for providing virtual TPM storage. They're willing to sell you one and Microsoft doesn't want you to operate Vista virtually without a trustworthy Trusted Platform Module. It may be inappropriate to build a system with absolute trust in TPM to protect intellectual property. There are other architectures that can do better, say a blade server running a virtual copy of an OS. The element providing greater security is removing the potentially malicious end-user from physical access, and not allowing access beyond the virtual machine. Thin clients and web applications come to mind for protecting corporate secrets, too. TPM is predicated on the notion that the corporate universe is comprised of fully capable computers. The idea for Trusted Computing comes mainly from hardware vendors, so the bias isn't surprising. No one likes the idea of TPM on their personal machines,it's really driven by enterprise needs, although you could imagine a market for a service intended to keep your personal Windows PC updated. There can be useful side effects to having TPM on personal computers. TPM could provide secure storage for keys to software or hardware encrypted disk drives, the alternative might imply uncovering the equivalent of master keys over questionable channels during boot up. Secure Disks with hardware
Re: Free Rootkit with Every New Intel Machine
David G. Koontz [EMAIL PROTECTED] writes: There are third party TPM modules, which could allow some degree of standardization: As I said in my previous message, just because they exist doesn't mean they'll do anything if you plug them into a MB with the necessary header (assuming you have a MB with the header, and it's physically compatible, and electrically compatible, and the BIOS is compatible, and ...). Which MBs have you plugged one of these TPMs into and had it work? TPM may well end up being present ubiquitously. Smart cards may well end up being present ubiquitously. Hardware RNGs may well end up being present ubiquitously. NIC-based crypto may well end up being present ubiquitously. Biometric readers may well end up being present ubiquitously. Home taping is killing mus... oops, wrong list. Been there, done that, got the tchotchkes to prove it. I've seen zero evidence that TPMs are going to be anything other than a repeat of hardware RNGs, NIC-based crypto, biometric readers, and the pile of other failed hardware silver bullets that crop up every few years. Wait a year or two and there'll be some other magic gadget along to fix all our problems. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Free Rootkit with Every New Intel Machine
| ...Apple is one vendor who I gather does include a TPM chip on their | systems, I gather, but that wasn't useful for me. Apple included TPM chips on their first round of Intel-based Macs. Back in 2005, there were all sorts of stories floating around the net about how Apple would use TPM to prevent OS X running on non-Apple hardware. In fact: - Some Apple models contain a TPM module (the Infineon TPM1.2); some (second generation) don't; - No current Apple model contains an EFI (boot) driver for the module; - No current version of OS X contains a driver to access the module for any purpose; - Hence: OS X doesn't rely on TPM to block execution on non- Apple hardware. In fact, there is an active hacker's community that gets OS X to run on hackintosh's - an announcement of OS X on a Sony Vaio made the rounds just a couple of days ago. Apparently the only real difficulty is writing appropriate boot and other low-level drivers. Amit Singh, the author of the definitive reference on OS X internals, has written and distributed an OS X driver for the TPM on those machines that have it. For all kinds of details, see his page at: http://www.osxbook.com/book/bonus/chapter10/tpm/ -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Herbert Yardley trivia
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemviewitem=item=180133437659#6376261103687981571 --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
fyi: SHA-2 patent status
of possible interest... Original Message Subject: [saag] SHA-2 patent status Date: Mon, 25 Jun 2007 09:55:46 -0700 From: Paul Hoffman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Of possible interest (but hopefully no concern) to this list: a new IPR statement from the NSA to the IETF. https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=858 --Paul Hoffman, Director --VPN Consortium ___ saag mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/saag - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Financial Cryptography CFP
Forwarded: From: Radu Sion [EMAIL PROTECTED] Subject: CFP: Financial Cryptography and Data Security 2008 [deadline: September 25] Date: Mon, 25 Jun 2007 13:07:37 -0400 Reply-To: Radu Sion [EMAIL PROTECTED] Dear Colleague, This is an advanced call for papers for the Financial Cryptography and Data Security Conference in Cozumel, Mexico, 28-31 January, 2008 (http://fc08.ifca.ai). Financial Cryptography and Data Security is a major international forum for research, advanced development, education, exploration, and debate regarding information assurance in the context of finance and commerce. The conference covers all aspects of securing transactions and systems. Submissions focusing on both fundamental and applied real-world deployments are solicited. This year, for the first time, we are also accepting submissions for posters and short papers. The poster session is the perfect venue to share a provocative opinion, interesting established or preliminary work, or a cool idea that will spark discussion. Poster presenters will benefit from a multi-hour session to discuss their work, get exposure, and receive feedback from attendees. The intention behind short papers (peer-reviewed) is to encourage authors to introduce work in progress, novel applications and corporate or industrial experiences. Short papers will be evaluated with a focus on novelty and potential for sparking participants' interest and future research avenues. DATES Submission: 25 September Posters: 13 November Panels: 13 November ORGANIZERS Program Chair: Gene Tsudik, UC Irvine General Chair: Radu Sion, Stony Brook Local Arrangement Chair: Rafael Hirschfeld, Unipay Poster Chair: Bogdan Carbunar, Motorola Labs Program Committee N. Asokan, Nokia Research Giuseppe Ateniese, Johns Hopkins University Nikita Borisov, University of Illinois, Urbana-Champaign George Danezis, Katholic University of Leuven Stefan Dziembowski, University of Rome Kevin Fu, University of Massachusetts, Amherst Philippe Golle, PARC Dieter Gollmann, Technical University of Hamburg-Harburg Aggelos Kiayias, Univeristy of Connecticut Javier Lopez, University of Malaga Arjen Lenstra, Swiss Federal Institute of Technology Lausanne Ninghui Li, Purdue University Patrick McDaniel, Pennsylvania State University Alessandro Mei, University of Rome Refik Molva, Eurecom Institute Pino Persiano, University of Salerno Ahmed Sadeghi, University of Bochum Michael Szydlo, Akamai Technologies Suzanne Wetzel, Stevens Institute of Technology For more details please see http://fc08.ifca.ai. We apologize if you receive multiple copies of this message. We did our best to avoid this. Please help us distribute this to other interested colleagues. Best Regards, Financial Cryptography and Data Security 2008 Organizers - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free Rootkit with Every New Intel Machine
David G. Koontz writes: There are third party TPM modules, which could allow some degree of standardization: http://www.ieiworld.com/en/news_content.asp?id=erbium/projectOBJ00244201news_cate=Newsnews_sub_cate=Product The IEI TPM module is used in their own motherboards and some VIA motherboards. They actively market the pluggable modules. Thinkpads appear to use a different connector: https://www.cosic.esat.kuleuven.be/publications/article-591.pdf 30 pins instead of 20 pins. It seems odd for the TPM of all devices to be put on a pluggable module as shown here. The whole point of the chip is to be bound tightly to the motherboard and to observe the boot and initial program load sequence. Any steps to decouple the TPM and facilitate separating it from a motherboard will only make attacks on its security model easier and make the chip less useful for its stated purpose. The idea of putting a TPM on a smart card or other removable device is even more questionable from this perspective. A TPM which communicates via an easily accessible and tamperable bus is almost useless for the security concepts behind the Trusted Computing Group architecture. (The exception might be if there were additional hardware to encrypt the bus, but that is not part of the standard spec.) The other direction that has been mentioned, putting the TPM onto the CPU die, would make more sense for security, but I don't know of any chips that actually do that. However with the future trend towards increased CPU parallelism and addition of extra cores for additional functionality, it would seem to be a natural extension, if TPMs catch on. I tried hunting through the TCG specs to see if they say anything about this, but it's a maze. Eventually there is supposed to be a Platform Conformance Credential which certifies that a particular platform (e.g. motherboard + associated chips) satisfies some criteria and has gone through a certification process. But I couldn't find anything specific about what security features a trusted platform is supposed to have. The TPM Design Principles doc says: https://www.trustedcomputinggroup.org/specs/TPM/Main_Part1_Rev94.zip 11.2 RTR to Platform Binding Start of informative comment When performing validation of the EK and the platform the challenger wishes to have knowledge of the binding of RTR to platform. The RTR is bound to a TPM hence if the platform can show the binding of TPM to platform the challenger can reasonably believe the RTR and platform binding. The TPM cannot provide all of the information necessary for the challenger to trust in the binding. That information comes from the manufacturing process and occurs outside the control of the TPM. End of informative comment 1. The EK is transitively bound to the Platform via the TPM as follows: a. An EK is bound to one and only one TPM (i.e., there is a one to one correspondence between an Endorsement Key and a TPM.) b. A TPM is bound to one and only one Platform. (i.e., there is a one to one correspondence between a TPM and a Platform.) c. Therefore, an EK is bound to a Platform. (i.e., there is a one to one correspondence between an Endorsement Key and a Platform.) Here, the RTR is the Root of Trust for Reporting, aka the on-chip Endorsement Key (EK) which the TPM uses to sign platform and software configuration info as part of its Remote Attestation capability. This text would seem to argue against a removable TPM. Here's a quote from one of the PC-related specs: https://www.trustedcomputinggroup.org/specs/PCClient/TCG_PCClientImplementationforBIOS_1-20_1-00.pdf 1.2.12.1.2 Binding Methods Start of informative comment The method of binding the TPM to the motherboard is an architectural and design decision made by the respective manufacturer and is not specified here. There are two types of binding: physical and logical. Physical binding relies on hardware techniques while logical binding relies on cryptographic techniques. The nature and strength of each method is defined by the TPM's or the Platform's Protection Profile. Example: The TPM is a physical chip soldered to the Host Platform. Here the Endorsement Key is physically bound to the TPM (it's inside it) and the TPM is physically bound to the Host Platform by the solder. The required strength of each binding is determined by the Protection Profile. End of informative comment So this would allow a removable TPM but it has to be logically bound to the motherboard via cryptography, presumably something like an encrypted bus. As Peter Gutmann noted, most TPM systems are relatively expensive business laptops where the chip is sold as a security chip, although in practice it doesn't do much. Possibly with Vista's BitLocker disk encryption we will see more use of TPMs. I saw the other day that Microsoft was about to make BitLocker available to home users (it's only in the high-end Vistas now) but changed their mind at the
Re: Why self describing data formats:
On Fri, 01 Jun 2007 20:59:55 +1000 James A. Donald [EMAIL PROTECTED] wrote: Many protocols use some form of self describing data format, for example ASN.1, XML, S expressions, and bencoding. Why? Presumably both ends of the conversation have negotiated what protocol version they are using (and if they have not, you have big problems) and when they receive data, they need to get the data they expect. If they are looking for list of integer pairs, and they get a integer string pairs, then having them correctly identified as strings is not going to help much. The most important reason is application flexibility -- very often, complex data structures are being passed around, and having some format like those makes life easier. There is some security benefit, though -- see Section 7 of Abadi and Needham's Prudent Engineering Practice for Cryptographic Protocols (1995). (Yes, they're calling for a lot less than full-blown ASN.1.) --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Free Rootkit with Every New Intel Machine
It seems odd for the TPM of all devices to be put on a pluggable module as shown here. The whole point of the chip is to be bound tightly to the motherboard and to observe the boot and initial program load sequence. Maybe I am showing my eternal optimist side here, but to me, this is how TPM's should be used, as opposed to the way their backers originally wanted them used. A removable module whose connection to a device I establish (and can de-establish, assuming the presence of a tamper-respondent barrier such as a sensor-enabled computer case to legitimize that activity) is a very useful thing to me, as it facilitates all sorts of useful applications. The utility of the original intent has already been widely criticised, so I won't repeat that here. :) It also shows those interesting economics at work. The added utility of the TPM module (from the PoV of the user) was marginal at best despite all claims, yet it facilitated functionality which was contrary to most user's interests. The content industry tried to claim that the TPM module would facilitate the availability of compelling content - which they tried to sell as it's user utility - but like most of their claims it was a smoke and mirrors trick. Consequently, the razor-edged economics of the motherboard and desktop industry has comprehensively rejected TPM except in certain specialized marketplaces where higher profit margins are available (eg. Servers, corporate desktops). The chipset manufacturers have also failed to add this functionality to their offerings to date. Now Vista has added Bitlocker, which arguably adds a user valuable feature for which a TPM module is needed (yes, you can run it without TPM, but it's painful). I wonder if we'll start to see more TPM connectors appearing, or even full TPM modules on motherboards and cores on south bridge dies? Personally, I'd like to see a TPM implemented as a tamper-respondent (ie. Self-powered) module mounted on the motherboard in a socket which allows removal detection. That way you get the flexibility of moving the module, with the safety of a programmed response to an unauthorized removal. Ian. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free Rootkit with Every New Intel Machine
On Mon, Jun 25, 2007 at 04:42:56PM +1200, David G. Koontz wrote: Apple (mis)uses TPM to unsuccessfully prevent OS X from running on non-Apple Hardware. All Apple on Intel machines have TPM, that's what 6 percent of new PCs? To nit pick, the TPM is only present in some Apple Intel machines and isn't used in any of them. See http://osxbook.com/book/bonus/chapter10/tpm/ Their OS decryption key is just stored in normal firmware, unprotected AIUI. Matt - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
