Re: TPM disk crypto
cyphrpunk wrote: 1. The issue is still moot at present. We are a long way from where open, public, remote attestion will be possible. See this diagram from the Trousers open-source TPM software stack project which shows which pieces are still missing: http://trousers.sourceforge.net/remote_attestation_deps.png so i did do fab process and associated infrastructure for tpm-like chips that recorded public key at manufacturing time. this came up in recent thread on trusting chips and/or knowing integrity level of chips http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#5 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea? http://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP: snake oil or good idea? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Travis H. wrote: I can validate everything else, but as long as the BIOS is motherboard-specific and closed source, I don't see why I should trust it. We need to get rid of this legacy crud. LinuxBIOS is a good step but unfortunately it is only supported on a few motherboards. We're shipping LinuxBIOS on the One Laptop per Child machines. No BIOS I know of has a semblance of security, given temporary physical access to the machine. I came up with a scheme that lets us do a secure BIOS without a TPM; bypassing it without a PLCC would be extremely difficult. I'm not yet certain if we'll end up shipping a PLCC socket on the final hardware, but if not, I suspect you'd be hard-pressed to do much to the BIOS protection even with physical access, short of un-soldering and re-soldering a different SPI flash chip to the motherboard. That was explicitly not part of my threat model. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Alexander Klimov wrote: Since a regular installation should not change ``reported OS hash,'' TPM will not be able to detect the difference. Am I missing something? You're missing the marketing value of saying this piece of hardware, that you probably wouldn't otherwise want in your machine since it makes sure that the machine can be trusted /against/ you, is great! Because it protects you against trojans! And everyone wants to be safe from trojans, right?. Btw, how the TCG allows to regularly change the kernel for security patches and still keep the same ``reported hash''? The Microsoft guy presenting BitLocker at HITB last month mentioned this, but glossed over it without explaining. He did seem to indicate that they had some solution, but didn't provide details, IIRC. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Kuehn, Ulrich wrote: Who is we? In the case of my own system I payed for (so speaking for myself) I would like to have such a mechanism to have the system prove to me before login that it is not tampered with. The TCG approach does not provide this. What does prove mean here? Does having a hash of the system state for visual inspection before boot do it? -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On 10/10/06, Adam Back [EMAIL PROTECTED] wrote: I think the current CPUs / memory managers do not have the ring -1 / curtained memory features, but already a year ago or more Intel and AMD were talking about these features. So its possible the for example hypervisor extra virtualization functionality in recent processors ties with those features, and is already delivered? Anyone know? Intel LaGrande Technology is supposed to ship soon and combines virtualization with TPM integration so you can load what they call a MVMM: a measured virtual machine monitor. Measured means the hash goes securely to the TPM so it can attest to it, and third parties can verify what VMM you are running. Then the security properties would depend on what the VMM enforces. The MVMM runs in what you might call ring -1, while the OS running in ring 0 has only virtualized access to certain system resources like page tables. One thing the MVMM could do is to measure and attest to OS properties. Then if you patched the OS to bypass a signed-driver check, it might not work right. One question that was raised is how these systems can be robust against OS upgrades and such. It would seem that ultimately this will require attestation to be based on a signing key rather than the code fingerprint. Rather than hashing the code it loads, the MVMM would verify that the code is signed by a certain key, and hash the key, sending that to the TPM. Then any code signed by the same key could produce the same attestation and have access to the same sealed data. The TCG infrastructure working group is supposed to standardize what kinds of attestions will be used and what they will mean. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
James A. Donald: Well obviously I trust myself, and do not trust anyone else all that much, so if I am the user, what good is trusted computing? One use is that I can know that my operating system has not changed behind the scenes, perhaps by a rootkit, know that not only have I not changed the operating system, but no one else has changed the operating system. Alexander Klimov wrote: The argument that TPM can prevent trojans seems to imply that the trojans are installed by modification of raw storage while the OS is offline. No it does not. Btw, how the TCG allows to regularly change the kernel for security patches and still keep the same ``reported hash''? It can report that the hash is a value that has been blessed by signed software - and can report that its list of reputable signing authorities is blessed by Microsoft, and does not include me. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Here is a posting from the cypherpunks mailing list describing the capabilities of Intel's new virtualization/TPM technology. Gets a bit ranty but still good information. CP -- Forwarded message -- From: Anonymous Remailer (austria) [EMAIL PROTECTED] Date: Fri, 29 Sep 2006 03:25:57 +0200 (CEST) Subject: Palladium is back. And this time, it's... To: [EMAIL PROTECTED] In the past few weeks new information has come out on the Trusted Computing (TC) front which provides clues to where this powerful and controversial technology may be heading. Much of this has come from Intel, which has revealed more information about their LaGrande technology, now un-codenamed to Trusted Execution Technology. A good source of links is the Hack the Planet blog, http://wmf.editthispage.com/ - scroll down to the September 25 entry. LaGrande was originally designed as the hardware support for Microsoft's now-defunct Palladium, relating to the differences between Palladium and TCPA (now called TCG). Both technologies relied on the TPM chip to take measurements of running software, report those measurements remotely via trusted attestations, and lock encrypted data to those measurements so that other software configurations could not decrypt it. These are the core capabilities which give TC its power. But there were important differences in the two approaches. TCPA was focused on a measured boot process. As the system boots, each stage would measure (i.e. hash into the TPM) the next stage before switching control to it. At the end of this process the TPM's Platform Configuration Registers would hold a fingerprint of the software configuration that had booted. With a TPM-aware OS the PCRs could be further updated as each program launches to keep an up-to-date picture of what is running. Palladium instead wanted to be able to switch to trusted mode in mid stream, after booting; and wanted to continue to run the legacy OS while new applications ran in the trusted area. LaGrande Technology (LT, now TET), in conjunction with new TPM capabilities offered in the 1.2 chips now available, would provide the support for this late launch concept. Palladium is now gone but Intel has continued to develop LaGrande and has now released documentation on how it will work, at http://www.intel.com/technology/security/. Late launch starts with the OS or the BIOS executing one of the new LT instructions. This triggers a complex sequence of operations whose purpose is to load, measure (ie hash into the TPM) and launch a hypervisor, that is, a Virtual Machine Monitor (VMM). The hypervisor can then repackage the state of the launching OS as a Virtual Machine (VM) and transfer control back to it. The OS has now become transparently virtualized and is running on top of the VMM. The VMM can then launch secure VMs which execute without being molested by the legacy OS. Another enhancement of LT is that the chipset can be programmed to prevent DMA access to specified memory areas. This will close a loophole in existing VMM systems, that VMs can program DMA devices to overwrite other VMs' memory. This protection is necessary for the TC goal of protected execution environments. Both VMWare and Xen are getting involved with this technology. As the blog entry above says, Intel donated code to Xen a few days ago to support much of this functionality, so that Xen will be able to launch in this way on TET machines. Another link from the blog entry is an amazing Intel presentation showing how excited the NSA is about this technology. Within a couple of years they will be able to acquire Commercial Off the Shelf (COTS) systems configured like this, that will allow running multiple instances of OS's with different security classifications. The slides show a system running two versions of Windows, one for Secret and one for Top Secret data, appearing in separate windows on the screen. Xen or VMWare with TET will be able to do this very soon if not already. Here's Intel's description of how software might be configured to use this capability, from their Trusted Execution Technology Architectural Overview linked from the LaGrande page above: Trusted Execution Technology provides a set of capabilities that can be utilized in many different operating environments (Figure 2). One proposed architecture provides a protection model similar to the following: A standard partition that provides an execution environment that is identical to today's IA-32 environment. In this environment, users will be able to run applications and other software just as they do on today's PC. The standard partition's obvious advantage is that it preserves the value of the existing code base (i.e. existing software does not need modification to run in the standard partition) and potential future software that is less security conscious. Unfortunately, it also retains the inherent vulnerabilities of today's environment. A protected partition provides a
RE: TPM disk crypto
From: Ivan Krstić [mailto:[EMAIL PROTECTED] Kuehn, Ulrich wrote: Who is we? In the case of my own system I payed for (so speaking for myself) I would like to have such a mechanism to have the system prove to me before login that it is not tampered with. The TCG approach does not provide this. What does prove mean here? Does having a hash of the system state for visual inspection before boot do it? Well, reliably obtaining the end of a hash chain would do, but it would be very inconvenient to compare that manually (visually) to a hash written on a piece of paper in my wallet. That is not user-friendly. However, if the system provided a possibility to reliably stop the boot process when something is changed, that would do. With reliably stopping the boot process I mean the following: Given that stage i of the process is running, it takes the hash of the next stage, compares that to an expected value. If they match, the current stage extends the TPM register (when also running the TCG stuff), and executes the next stage. If the computed and expected hashes do not match, the machine goes into a predetermined halt state. Predetermined means that the system administrator (on behalf of the system owner) can determine the expected hash value. I hope this makes it clear what I meant in the text quoted above. To implement this the TCG-preBIOS would need to implement this halt state, possibly along with some other additional features like where to store the expected hashes etc. Cheers, Ulrich - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On 10/13/06, Kuehn, Ulrich [EMAIL PROTECTED] wrote: With reliably stopping the boot process I mean the following: Given that stage i of the process is running, it takes the hash of the next stage, compares that to an expected value. If they match, the current stage extends the TPM register (when also running the TCG stuff), and executes the next stage. If the computed and expected hashes do not match, the machine goes into a predetermined halt state. Predetermined means that the system administrator (on behalf of the system owner) can determine the expected hash value. You don't need the TPM for this. You could imagine a boot process where each stage hashed the next stage, and refused to proceed if it didn't match an expected value. One question though is how you prevent malware from changing these expected values, even potentially reflashing the BIOS. A student project at Dartmouth a few years ago, enforcer.sourceforge.net, worked like this. It could also optionally use a TPM but didn't have to. The project appears to be abandoned but the supervising professor, Sean Smith, in his book Trusted Computing Platforms says that new students are bringing it up to date, getting it working with newer kernels including selinux support. Here's the Enforcer description. Nice piece of work. Hopefully they'll release an updated version now that TPMs are more common. The Enforcer is a Linux Security Module designed to improve integrity of a computer running Linux by ensuring no tampering of the file system. It can interact with TCPA hardware to provide higher levels of assurance for software and sensitive data. It can check, as every file is opened, if the file has been changed, and take an admin specified action when it detects tampering. The actions can be any combination of log the error, deny access to the file, panic the system, or several operations that work with the TPM. The Enforcer can also work with the TPM to store the secret to an encrypted loopback file system, and unmount this file system when a tampered file is detected. The secret will not be accessible to mount the loopback file system until the machine has been rebooted with untampered files. This allows sensitive data to be protected from an attacker. The Enforcer can also bind specific files so that only specific applications can access them (for example, only apache is allowed to access apache's secret ssl key). This means that even if someone compromises your system, the attacker will not be able to steal critical files. Finally, the Enforcer can make sure that no files added to directories after its database is built are allowed to be accessed. One thing they worked hard on in the design is the balance between detecting malicious changes, and allowing necessary changes for maintenance and upgrades. They identified different classes of components that were updated seldom, occasionally or frequently, and architected the system to provide an appropriate degree of checking for each category. The academic paper is here: http://www.cs.dartmouth.edu/~sws/abstracts/mswm03.shtml CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On Mon, 9 Oct 2006 kkursawe at esat.kuleuven.ac.be wrote: IIUC, TPM is pointless for disk crypto: if your laptop is stolen the attacker can reflash BIOS and bypass TPM. According to TCG Specification, the first part of the BIOS (called Core Root of Trust for Measurement) should be non-flashable; this part then checksums the rest of the BIOS, option ROMS etc. and reports those to the TPM. I don't know how this is done in devices currently sold, but at least it should not be trivial to reprogram that part of the BIOS. Even if BIOS is real ROM, but there are some inter-chip links between ROM, CPU, and TPM, it seems possible for an attacker with an iron and FPGAs to trick the TPM to reveal the secret. That is against highly-motivated attacker TPM does not give really more protection than truecrypt, but for a casual attacker (who is just curious what is on a stolen laptop) even truecrypt is enough. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: TPM disk crypto
From: James A. Donald [mailto:[EMAIL PROTECTED] Sent: Dienstag, 10. Oktober 2006 06:40 What we want is that a bank client can prove to the bank it is the real client, and not trojaned. What the evil guys at RIAA want is that their music player can prove it is their real music player, and not hacked by the end user. Having a system that will only boot up in a known state is going to lead to legions of unhappy customers who find their system does not come up at all. Who is we? In the case of my own system I payed for (so speaking for myself) I would like to have such a mechanism to have the system prove to me before login that it is not tampered with. The TCG approach does not provide this. Oh, and predetermined means that the machine admin can declare to which known state the system is going to boot. From a company point of view it might be interesting to make sure the employees have systems that come up to a predetermined state, or not at all, so when infected this turns up at next boot so that the admin can fix it. Here the TCG approach would also be helpful as the remote attestation against a central server (or a number of them) can help. And for the RIAA guys, they have no business on the machine I did pay for (!), as long as I do not infringe their copyright. Assumed innocent until proven guilty! On the other hand, there has been an infamous record company that miserably failed to ensure their components on consumers' computers are _not_ a security risk. Ulrich - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
I was suspecting that as DRM at least appears to one of the main motivators (along side trojan/malware protection) for trustworthy computing that probably you will not be able to put the TPM into debug mode (ie manipulate code without affecting the hash attested in debug mode). Ability to do so breaks DRM. Also bear in mind the vista model where it has been described that inserting an unsigned device driver into the kernel will disable some media playback (requiring DRM). And also the secure (encrypted) path between trusted agent and video/audio card, and between video/audio card and monitor/speakers. The HDMI spec has these features, and you can already buy HDMI cards and monitors (though I dont know if they have the encryption features implemented/enabled). I think generally full user control model will not be viewed compatible. Ie there will be a direct conflict between user ability to debug attested apps and DRM. So then enters the possibility to debug all apps except special ones flagged as DRM, but if that technical ability is there, you wont have wait long for it to be used for all things: file formats locked to editors, per processor encrypted binaries, rented by the hour software you cant debug or inspect memory space of etc. I think the current CPUs / memory managers do not have the ring -1 / curtained memory features, but already a year ago or more Intel and AMD were talking about these features. So its possible the for example hypervisor extra virtualization functionality in recent processors ties with those features, and is already delivered? Anyone know? The device driver signing thing is clearly bypassable without a TPM, and we know TPMs are not widely available at present. (All that is required is to disable or nop out the driver signature verification in the OS; or replace the CA or cert it is verified against with your own and sign your own drivers). How long until that OS binary patch is made? Adam On Tue, Oct 10, 2006 at 12:56:07PM +0100, Brian Gladman wrote: I haven't been keeping up to date with this trusted computing stuff over the last two years but when I was last involved it was accepted that it was vital that the owner of a machine (not necessarily the user) should be able to do the sort of things you suggest and also be able to exert ultimate control over how a computing system presents itself to the outside world. Only in this way can we undermine the treacherous computing model of trusted machines with untrusted owners and replace it with a model in which trust in this machine requires trust in its owner on which real information security ultimately depends (I might add that even this model has serious potential problems when most machine owners do not understand security). Does anyone know the current state of affairs on this issue within the Trusted Computing Group (and the marketed products of its members)? Adam Back wrote: So the part about being able to detect viruses, trojans and attest them between client-server apps that the client and server have a mutual interest to secure is fine and good. The bad part is that the user is not given control to modify the hash and attest as if it were the original so that he can insert his own code, debug, modify etc. (All that is needed is a debug option in the BIOS to do this that only the user can change, via BIOS setup.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On Mon, 9 Oct 2006, James A. Donald wrote: Well obviously I trust myself, and do not trust anyone else all that much, so if I am the user, what good is trusted computing? One use is that I can know that my operating system has not changed behind the scenes, perhaps by a rootkit, know that not only have I not changed the operating system, but no one else has changed the operating system. The argument that TPM can prevent trojans seems to imply that the trojans are installed by modification of raw storage while the OS is offline. Probably, this can be a case for malicious internet-cafes, but 99.9% of trojans on home PCs of normal people are installed when the OS is active (0.1% is for trojans installed by law enforcement). (Of course, an attacker with physical access can install physical trojans: hardware keylogger and camera.) Since a regular installation should not change ``reported OS hash,'' TPM will not be able to detect the difference. Am I missing something? Btw, how the TCG allows to regularly change the kernel for security patches and still keep the same ``reported hash''? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
What we want is that a bank client can prove to the bank it is the real client, and not trojaned. What the evil guys at RIAA want is that their music player can prove it is their real music player, and not hacked by the end user. Having a system that will only boot up in a known state is going to lead to legions of unhappy customers who find their system does not come up at all. Having remote attestation that provides signed checksums of every stage of the startup process, which are checked by guys at the RIAA or guys at the bank, will lead to legions of unhappy customers who find their system boots fine, but is denied access to both the bank and the music store. (Seventy thousand totally valid configurations are not going to be checked and confirmed by either one.) But their system will access the Darknet just fine. John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On 10/9/06, Adam Back [EMAIL PROTECTED] wrote: The bad part is that the user is not given control to modify the hash and attest as if it were the original so that he can insert his own code, debug, modify etc. (All that is needed is a debug option in the BIOS to do this that only the user can change, via BIOS setup.) Actually, it's the BIOS I don't trust. I can validate everything else, but as long as the BIOS is motherboard-specific and closed source, I don't see why I should trust it. We need to get rid of this legacy crud. LinuxBIOS is a good step but unfortunately it is only supported on a few motherboards. No BIOS I know of has a semblance of security, given temporary physical access to the machine. BTW, the x86 microcode updates are performed by the BIOS IIRC and require no hardware settings. Is there any reason you can't update the processor microcode later on in the boot process? -- The obvious mathematical breakthrough would be the development of an easy way to factor large prime numbers.'' [sic] -- Bill Gates -- URL:http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On 10/10/06, Brian Gladman [EMAIL PROTECTED] wrote: I haven't been keeping up to date with this trusted computing stuff over the last two years but when I was last involved it was accepted that it was vital that the owner of a machine (not necessarily the user) should be able to do the sort of things you suggest and also be able to exert ultimate control over how a computing system presents itself to the outside world. Only in this way can we undermine the treacherous computing model of trusted machines with untrusted owners and replace it with a model in which trust in this machine requires trust in its owner on which real information security ultimately depends (I might add that even this model has serious potential problems when most machine owners do not understand security). Does anyone know the current state of affairs on this issue within the Trusted Computing Group (and the marketed products of its members)? 1. The issue is still moot at present. We are a long way from where open, public, remote attestion will be possible. See this diagram from the Trousers open-source TPM software stack project which shows which pieces are still missing: http://trousers.sourceforge.net/remote_attestation_deps.png There is actually another important piece missing from that diagram, namely operating system support. At present the infrastructure would only allow attestation at the OS-boot level, i.e. you could prove what OS you booted. It's a big step from there to proving that you are running a safe application, unless the service would require you to reboot your machine into their OS every time you want to run their client. 2. Not an insider, but I haven't heard anything about serious efforts to implement Owner Override or similar proposals. Instead, the response seems to be to wait and hope all that fuss blows over. 3. What little evidence exists suggests that TCG is going in the opposite direction. The 1.2 TPM is designed to work with Intel's Lagrange Technology which will add improved process isolation and late launch. This will make it possible to attest at the level of individual applications, and provide protection against the local user that a plain TPM system can't manage. 1.2 also adds a cryptographically blinded attestation mode that gets rid of the ugly privacy ca which acted as a TTP in 1.1, and which will make it easier to move towards attestation. 4. Software remains the biggest question mark, and by software I mean Microsoft. They have said nothing about attestation support in Vista. Given the hostile response to Palladium I doubt there is much enthusiasm about jumping back into that crocodile pit. It doesn't seem to be stopping HD-DVD from moving forward, even though there is no credible probability of an attestation feature appearing in the time frame needed for these new video product introductions. Without a driving market force to introduce attestation, and tremendous social resistance, the status quo will probably prevail for another couple of years. By that time LT will be available, TPMs will be nearly universal but used only for improved local security, and perhaps some tentative steps into attestation will appear. The initial version might be targeted at corporate VPNs which will prevent mobile employees from connecting unless their laptops attest as clean. This would be an uncontroversial use of the technology except for its possible implications as a first step towards wider use. Whether we will eventually ever see the whole model, with attestation, process isolation, sealed storage, and trusted i/o path all leading to super-DRM, is very much an open question. So many barriers exist between here and there that it seems unlikely that this will be seen by anyone as the right solution to that problem, by then. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
-- Kuehn, Ulrich wrote: However, this is the big problem with the TPM according to the TCG spec. While you can remotely verify that the system came up according to what you installed there, you have no means to force it to either come up the way you want, or to be in a clear error state. That is the huge difference between the verifiable booting the TPM provides and secure booting, which would run only predetermined software. I assume that the TCG chose not to implement the latter due to fear of public bashing... What we want is that a bank client can prove to the bank it is the real client, and not trojaned. What the evil guys at RIAA want is that their music player can prove it is their real music player, and not hacked by the end user. Having a system that will only boot up in a known state is going to lead to legions of unhappy customers who find their system does not come up at all. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG mzJSAlA4uoeaqcIPwxmdSTaMGpCr10BSXet2rKo+ 4C0qq8mGmz37gK89YinlEpVVumD1TtkcDOd8iHHGh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Adam Back wrote: So the part about being able to detect viruses, trojans and attest them between client-server apps that the client and server have a mutual interest to secure is fine and good. The bad part is that the user is not given control to modify the hash and attest as if it were the original so that he can insert his own code, debug, modify etc. (All that is needed is a debug option in the BIOS to do this that only the user can change, via BIOS setup.) I haven't been keeping up to date with this trusted computing stuff over the last two years but when I was last involved it was accepted that it was vital that the owner of a machine (not necessarily the user) should be able to do the sort of things you suggest and also be able to exert ultimate control over how a computing system presents itself to the outside world. Only in this way can we undermine the treacherous computing model of trusted machines with untrusted owners and replace it with a model in which trust in this machine requires trust in its owner on which real information security ultimately depends (I might add that even this model has serious potential problems when most machine owners do not understand security). Does anyone know the current state of affairs on this issue within the Trusted Computing Group (and the marketed products of its members)? Brian Gladman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: TPM disk crypto
From: Erik Tews [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 5. Oktober 2006 23:52 [...] Later, you can remotely query your system and get a report what has been bootet on your system. You can do this query using a java application and tpm4java. However, this is the big problem with the TPM according to the TCG spec. While you can remotely verify that the system came up according to what you installed there, you have no means to force it to either come up the way you want, or to be in a clear error state. That is the huge difference between the verifiable booting the TPM provides and secure booting, which would run only predetermined software. I assume that the TCG chose not to implement the latter due to fear of public bashing... Ulrich - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On Fri, 6 Oct 2006, Erik Tews wrote: And the TPM knows that your BIOS has not lied about the checksum of grub how? The TPM does not know that the BIOS did not lie about the checksum of grub or any other bios component. What you do is, you trust your TPM and your BIOS that they never lie to you, because they are certified by the manufature of the system and the tpm. (This is why it is called trusted computing) IIUC, TPM is pointless for disk crypto: if your laptop is stolen the attacker can reflash BIOS and bypass TPM. Moreover, TPM is actually bad for disk crypto: without it you lose your data only if your HDD dies, now you lose your data if your HDD dies *or* if you motherboard dies. If the user is not experienced in BIOS reflashing, they also lose their data if OS crashes and refuses to boot (not uncommon for some common OSes). -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Erik Tews wrote: What you do is, you trust your TPM and your BIOS that they never lie to you, because they are certified by the manufature of the system and the tpm. (This is why it is called trusted computing) So if you don't trust your hardware and your manufactor, trusted computing is absolutely worthless for you. But if you trust a manufactor, the manufactor trusts the tpms he has build and embedded in some systems, and you don't trust a user that he did not boot a modified version of your operating system, you can use these components to find out if the user is lieing. Well obviously I trust myself, and do not trust anyone else all that much, so if I am the user, what good is trusted computing? One use is that I can know that my operating system has not changed behind the scenes, perhaps by a rootkit, know that not only have I not changed the operating system, but no one else has changed the operating system. Further, I can know that a known program on a known operating system has not been changed by a trojan. So if I have a login and banking client program, which communicates to me over a trusted path, I can know that the client is the unchanged client running on the unchanged operating system, and has not been modified or intercepted by some trojan. Further, the bank can know this, and can just not let me login if there is something funny about client program or the OS. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
So the part about being able to detect viruses, trojans and attest them between client-server apps that the client and server have a mutual interest to secure is fine and good. The bad part is that the user is not given control to modify the hash and attest as if it were the original so that he can insert his own code, debug, modify etc. (All that is needed is a debug option in the BIOS to do this that only the user can change, via BIOS setup.) Adam On Mon, Oct 09, 2006 at 08:03:40PM +1000, James A. Donald wrote: Erik Tews wrote: What you do is, you trust your TPM and your BIOS that they never lie to you, because they are certified by the manufature of the system and the tpm. (This is why it is called trusted computing) So if you don't trust your hardware and your manufactor, trusted computing is absolutely worthless for you. But if you trust a manufactor, the manufactor trusts the tpms he has build and embedded in some systems, and you don't trust a user that he did not boot a modified version of your operating system, you can use these components to find out if the user is lieing. Well obviously I trust myself, and do not trust anyone else all that much, so if I am the user, what good is trusted computing? One use is that I can know that my operating system has not changed behind the scenes, perhaps by a rootkit, know that not only have I not changed the operating system, but no one else has changed the operating system. Further, I can know that a known program on a known operating system has not been changed by a trojan. So if I have a login and banking client program, which communicates to me over a trusted path, I can know that the client is the unchanged client running on the unchanged operating system, and has not been modified or intercepted by some trojan. Further, the bank can know this, and can just not let me login if there is something funny about client program or the OS. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Alexander Klimov schrieb: On Fri, 6 Oct 2006, Erik Tews wrote: And the TPM knows that your BIOS has not lied about the checksum of grub how? The TPM does not know that the BIOS did not lie about the checksum of grub or any other bios component. What you do is, you trust your TPM and your BIOS that they never lie to you, because they are certified by the manufature of the system and the tpm. (This is why it is called trusted computing) IIUC, TPM is pointless for disk crypto: if your laptop is stolen the attacker can reflash BIOS and bypass TPM. Moreover, TPM is actually bad for disk crypto: without it you lose your data only if your HDD dies, now you lose your data if your HDD dies *or* if you motherboard dies. If the user is not experienced in BIOS reflashing, they also lose their data if OS crashes and refuses to boot (not uncommon for some common OSes). There is a great risk of data loss if the TPM protection is badly implemented. You can, however, store an encrypted key in your (not encrypted) hard disk, and save the decryption key both inside the TPM (bound to valid bios/boot loader/Kernel/OS PCR values) *and* in a second place for emergency recovery (like a memory stick in a safe). This way, the data on the hard disk can only be decrypted, if the unaltered operating system is used - the TPM will not decrypt the bound data if the system state changed. Of course, after reflashing your bios, you need to use your second key credential (once). -- Martin Hermanowski http://martin.hermanowski.name https://www.openbc.com/hp/Martin_Hermanowski/ signature.asc Description: OpenPGP digital signature
Re: TPM disk crypto
On Thu, Oct 05, 2006 at 11:51:49PM +0200, Erik Tews wrote: Am Donnerstag, den 05.10.2006, 16:25 -0500 schrieb Travis H.: On 10/2/06, Erik Tews [EMAIL PROTECTED] wrote: Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.: Anyone have any information on how to develop TPM software? http://tpm4java.datenzone.de/ Using this lib, you need less than 10 lines of java-code for doing some simple tpm operations. Interesting, but not what I meant. I want to program the chip to verify that the BIOS, boot sector, root partition conform to *my* specification. You can do that (at least in theory). First, you need a system with tpm. I assume you are running linux. Then you boot your linux-kernel and an initrd using the trusted grub bootloader. Your bios will report the checksum of trusted grub to the tpm before giving control to your grub bootloader. And the TPM knows that your BIOS has not lied about the checksum of grub how? Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Am Freitag, den 06.10.2006, 17:29 -0400 schrieb Thor Lancelot Simon: On Thu, Oct 05, 2006 at 11:51:49PM +0200, Erik Tews wrote: Am Donnerstag, den 05.10.2006, 16:25 -0500 schrieb Travis H.: On 10/2/06, Erik Tews [EMAIL PROTECTED] wrote: Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.: Anyone have any information on how to develop TPM software? http://tpm4java.datenzone.de/ Using this lib, you need less than 10 lines of java-code for doing some simple tpm operations. Interesting, but not what I meant. I want to program the chip to verify that the BIOS, boot sector, root partition conform to *my* specification. You can do that (at least in theory). First, you need a system with tpm. I assume you are running linux. Then you boot your linux-kernel and an initrd using the trusted grub bootloader. Your bios will report the checksum of trusted grub to the tpm before giving control to your grub bootloader. And the TPM knows that your BIOS has not lied about the checksum of grub how? The TPM does not know that the BIOS did not lie about the checksum of grub or any other bios component. What you do is, you trust your TPM and your BIOS that they never lie to you, because they are certified by the manufature of the system and the tpm. (This is why it is called trusted computing) So if you don't trust your hardware and your manufactor, trusted computing is absolutely worthless for you. But if you trust a manufactor, the manufactor trusts the tpms he has build and embedded in some systems, and you don't trust a user that he did not boot a modified version of your operating system, you can use these components to find out if the user is lieing. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: TPM disk crypto
On 10/2/06, Erik Tews [EMAIL PROTECTED] wrote: Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.: Anyone have any information on how to develop TPM software? http://tpm4java.datenzone.de/ Using this lib, you need less than 10 lines of java-code for doing some simple tpm operations. Interesting, but not what I meant. I want to program the chip to verify that the BIOS, boot sector, root partition conform to *my* specification. I don't want binary-only hardware-enforced vendor lock-in, that went out of fashion with the mainframe and proprietary data[base] formats. -- TH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
On 10/5/06, Erik Tews [EMAIL PROTECTED] wrote: First, you need a system with tpm. I assume you are running linux. Then you boot your linux-kernel and an initrd using the trusted grub bootloader. Your bios will report the checksum of trusted grub to the tpm before giving control to your grub bootloader. Your grub bootloader will then report the checksum of your kernel and your initrd to the tpm before giving control to them. Awesome, that's incredibly useful information. I had not heard of trusted grub. Thanks! One thing you should know is, that a tpm can never find out, if a software meets some specifications, like does not have an buffer overflow or does not execute code from the network or so. You just can check is has not been altered. Of course. However, you can sandbox x86 code efficiently: http://www.usenix.org/events/sec06/tech/mccamant/mccamant_html/index.html -- Enhance your calm, fellow citizen; it's just ones and zeroes. Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
TPM disk crypto
Quoting: Disk drives gear up for a lockdown Rick Merritt, EE Times (09/25/2006 9:00 AM EDT) Built-in security is the next big thing for hard-disk drives. By 2008, drive makers should be shipping in volume a broad array of drives based on a maturing standard. ... The first version of the Trusted Computing Group's standard for disk drive security could be completed by year's end. Seagate Technology Inc. already ships one drive with an integrated security chip, although some see that approach as an interim step. For mass production, security has to be integrated into the controller. It's not that many gates, even if the function is not used, said A. Currie Munce, vice president of research for Hitachi Global Storage Technologies. Seagate CTO Mark Kryder agreed, saying his company will integrate security functions in the drive controller very soon. A security standard will open the door to selling drives preloaded with content that users can unlock after paying online for a digital key...' === Anyone know if this is going to be compatible with the IEEE SISWG standard? Anyone have any information on how to develop TPM software? Anyone else recognize how features migrate from the CPU to an add-on card and back to the CPU? Same thing happened with RAID and on-board video and so on... it seems to me that people need an open-source add-in card for crypto, perhaps based around an FPGA, that is updatable if the algorithms need strengthening. It seems that Peter Gutmann has already done something similar: http://www.cypherpunks.to/~peter/usenix00.pdf -- Enhance your calm, fellow citizen; it's just ones and zeroes. Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TPM disk crypto
Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.: Anyone have any information on how to develop TPM software? Yes, thats easy. We created a java library for the tpm chip. You can get it at http://tpm4java.datenzone.de/ Using this lib, you need less than 10 lines of java-code for doing some simple tpm operations. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
