http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed feature for F16. We've traditionally had a hard objection to the functionality because it required either the distribution or downloading of binary code that ran on the host CPU, but it seems that there'll shortly be systems that incorporate the appropriate sinit blob in their BIOS, which is a boundary we've traditionally been fine with.
However, this is the kind of feature that has a pretty significant impact on the distribution as a whole. Fesco decided that we should probably have a broader discussion about the topic. The most obvious issues are finding a sensible way to incorporate this into Anaconda, but it's also then necessary to make sure that bootloader configuration is updated appropriately.
Outside that, is there any other impact? Does tboot perform any verification of the kernels, and if so how is that configured? Is the expectation that an install configured with TXT will only boot trusted kernels, and if so what mechanism is used to verify the kernel? Is there any further integration work that has to be performed for this to be useful?
http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed feature for F16. We've traditionally had a hard objection to the functionality because it required either the distribution or downloading of binary code that ran on the host CPU, but it seems that there'll shortly be systems that incorporate the appropriate sinit blob in their BIOS, which is a boundary we've traditionally been fine with.
However, this is the kind of feature that has a pretty significant impact on the distribution as a whole. Fesco decided that we should probably have a broader discussion about the topic. The most obvious issues are finding a sensible way to incorporate this into Anaconda, but it's also then necessary to make sure that bootloader configuration is updated appropriately.
Outside that, is there any other impact? Does tboot perform any verification of the kernels, and if so how is that configured? Is the expectation that an install configured with TXT will only boot trusted kernels, and if so what mechanism is used to verify the kernel? Is there any further integration work that has to be performed for this to be useful?
If so, is there a mechanism to disable that functionality, or mark a kernel as trusted, so that I could, for example, run a kernel I built myself or one from another RPM?
-J
-- Matthew Garrett | mjg59@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 2011-06-22 at 14:01 -0500, Jon Ciesla wrote:
http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed feature for F16. We've traditionally had a hard objection to the functionality because it required either the distribution or downloading of binary code that ran on the host CPU, but it seems that there'll shortly be systems that incorporate the appropriate sinit blob in their BIOS, which is a boundary we've traditionally been fine with.
However, this is the kind of feature that has a pretty significant impact on the distribution as a whole. Fesco decided that we should probably have a broader discussion about the topic. The most obvious issues are finding a sensible way to incorporate this into Anaconda, but it's also then necessary to make sure that bootloader configuration is updated appropriately.
Outside that, is there any other impact? Does tboot perform any verification of the kernels, and if so how is that configured? Is the expectation that an install configured with TXT will only boot trusted kernels, and if so what mechanism is used to verify the kernel? Is there any further integration work that has to be performed for this to be useful?
If so, is there a mechanism to disable that functionality, or mark a kernel as trusted, so that I could, for example, run a kernel I built myself or one from another RPM?
I would say that if this feature prevents users from creating their own trusted kernels we shouldn't probably care supporting it.
Simo.
I'm curious to know the use case(s) for this technology.
Does it enable certain types of behaviour that aren't possible currently?
Would it enable a system running Fedora to interact with other systems with a greater guarantee about its behaviour or function?
Is it just something that system integrators would see as a feature enabling them to make a secured system (ie something useful for RHEL)?
If it just allows you to optionally run a signed kernel, I don't understand the point if it can be circumvented by choosing to run an unsigned one. So I think there must be some benefit that isn't obvious. What's the benefit?
-Cam
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/22/2011 04:57 PM, Camilo Mesias wrote:
I'm curious to know the use case(s) for this technology.
Does it enable certain types of behaviour that aren't possible currently?
Would it enable a system running Fedora to interact with other systems with a greater guarantee about its behaviour or function?
Is it just something that system integrators would see as a feature enabling them to make a secured system (ie something useful for RHEL)?
If it just allows you to optionally run a signed kernel, I don't understand the point if it can be circumvented by choosing to run an unsigned one. So I think there must be some benefit that isn't obvious. What's the benefit?
-Cam
The idea is to allow certain tools/machines to make judgments on how "trusted" a machine is. For example you could set up a VPN server that says I will only allow a machine that passes the "Trusted" test to join my network. Another potential example would be to not allow a guest machine to run on your host if its OS is not "Trusted" Or to have a guest OS check to see if the Host Server is Trusted or stop running.
On Wed, 22 Jun 2011, Simo Sorce wrote:
If so, is there a mechanism to disable that functionality, or mark a kernel as trusted, so that I could, for example, run a kernel I built myself or one from another RPM?
I would say that if this feature prevents users from creating their own trusted kernels we shouldn't probably care supporting it.
After digging through the sparse documentation, it seems the lcptools package is how you would do this, although it's not really clear at all. The LCP user tools manual was last updated in 2007.
The tboot package doesn't seem to have been updated since 2010.
Is this being actively maintained?
- James
On 06/22/2011 03:01 PM, Jon Ciesla wrote:
Outside that, is there any other impact? Does tboot perform any verification of the kernels, and if so how is that configured? Is the expectation that an install configured with TXT will only boot trusted kernels, and if so what mechanism is used to verify the kernel? Is there any further integration work that has to be performed for this to be useful?
If so, is there a mechanism to disable that functionality, or mark a kernel as trusted, so that I could, for example, run a kernel I built myself or one from another RPM?
By default this would not be enabled. And even if so, out of the box the only thing it will ever do it measure the kernel you built and store that info. You would be able to create your own lcp which only allowed whatever kernels you wished, but that's a whole different issue than what is being asked for here.
-Eric
On 06/22/2011 03:01 PM, Jon Ciesla wrote:
Outside that, is there any other impact? Does tboot perform any verification of the kernels, and if so how is that configured? Is the expectation that an install configured with TXT will only boot trusted kernels, and if so what mechanism is used to verify the kernel? Is there any further integration work that has to be performed for this to be useful?
If so, is there a mechanism to disable that functionality, or mark a kernel as trusted, so that I could, for example, run a kernel I built myself or one from another RPM?
By default this would not be enabled. And even if so, out of the box the only thing it will ever do it measure the kernel you built and store that info. You would be able to create your own lcp which only allowed whatever kernels you wished, but that's a whole different issue than what is being asked for here.
Ok. What information is stored where and how?
-J
-Eric
On Wed, 2011-06-22 at 20:02 +0100, Matthew Garrett wrote:
http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed feature for F16. We've traditionally had a hard objection to the functionality because it required either the distribution or downloading of binary code that ran on the host CPU, but it seems that there'll shortly be systems that incorporate the appropriate sinit blob in their BIOS, which is a boundary we've traditionally been fine with.
However, this is the kind of feature that has a pretty significant impact on the distribution as a whole. Fesco decided that we should probably have a broader discussion about the topic. The most obvious issues are finding a sensible way to incorporate this into Anaconda, but it's also then necessary to make sure that bootloader configuration is updated appropriately.
Outside that, is there any other impact? Does tboot perform any verification of the kernels, and if so how is that configured? Is the expectation that an install configured with TXT will only boot trusted kernels, and if so what mechanism is used to verify the kernel? Is there any further integration work that has to be performed for this to be useful?
Are we going to continue the double grub entries? while I realize that tboot SHOULD allow non TXT hw to boot properly I also realize that any differences will be pointed to as a point of contention when debugging semirelated problems. so it seems like the double entries are wise.
Additionally, is the grub modifyication implemented in grubby and does this behave properly on a yum update of the kernel?
-sv
On 06/22/2011 03:20 PM, seth vidal wrote:
On Wed, 2011-06-22 at 20:02 +0100, Matthew Garrett wrote:
Are we going to continue the double grub entries? while I realize that tboot SHOULD allow non TXT hw to boot properly I also realize that any differences will be pointed to as a point of contention when debugging semirelated problems. so it seems like the double entries are wise.
Additionally, is the grub modifyication implemented in grubby and does this behave properly on a yum update of the kernel?
I'd say how to handle the grub entries is basically the entire point of the feature request. I was surprised to learn the other day that they filed a request at all since this was really just about making a change to grubby. I don't know how they plan to handle it.
Systems which don't support TXT are easy. They will work fine. The CPU won't say it supports TXT and tboot will just move along.
The real problem is systems which claim to support TXT, but then don't. tboot is actually really smart and will record that it tried a TXT enabled boot and if it fails will not use the TXT instructions the next time (this happens on things like the Lenovo x201). On other platforms, like the Lenovo x210 TXT does something when setting the iommu's in a safe state which causes the video card to go haywire when it tries to get set up. Now tboot can't tell this, since TXT completed and the kernel did actually launch successfully, but I'd imagine half ass broken hardware won't be common for too long. Intel had a kernel patch they thought would fix the problem, but I lost access to the system in question before I could test it (and I don't know if it was sent upstream)
Systems which ACTUALLY support TXT are easy. They just work and you don't even know your kernel was measured and and the iommus programmed to be safe before it launched.
So yeah, installing tboot if it automatically enables itself can be a problem on some broken hardware. I would certainly recommend against making tboot a part of the default install. But if a user installs it, it should 'just work', without manually updating grub on ever kernel update.
-Eric
Eric Paris wrote on 2011-06-23:
On 06/22/2011 03:20 PM, seth vidal wrote:
On Wed, 2011-06-22 at 20:02 +0100, Matthew Garrett wrote:
Are we going to continue the double grub entries? while I realize that tboot SHOULD allow non TXT hw to boot properly I also realize that any differences will be pointed to as a point of contention when debugging semirelated problems. so it seems like the double entries are wise.
Additionally, is the grub modifyication implemented in grubby and does this behave properly on a yum update of the kernel?
I'd say how to handle the grub entries is basically the entire point of the feature request. I was surprised to learn the other day that they filed a request at all since this was really just about making a change to grubby. I don't know how they plan to handle it.
What we want to do is just provide an easy-to-be-found option on install UI to select tboot package, and handle the grub entries while doing tboot package installation. We just want to follow what xen package previously did. We will look into details for how to achieve it via coordination among Anaconda/grubby/tboot package.
So yeah, installing tboot if it automatically enables itself can be a problem on some broken hardware. I would certainly recommend against making tboot a part of the default install. But if a user installs it, it should 'just work', without manually updating grub on ever kernel update.
We are not seeking for making tboot a part of the default install, just want to make the tboot install/configuration easier for end users.
BTW, I am trying to update the tboot feature page to include more documentations and other necessary information.
Jimmy
On 06/22/2011 03:02 PM, Matthew Garrett wrote:
http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed feature for F16. We've traditionally had a hard objection to the functionality because it required either the distribution or downloading of binary code that ran on the host CPU, but it seems that there'll shortly be systems that incorporate the appropriate sinit blob in their BIOS, which is a boundary we've traditionally been fine with.
Such systems supposedly exist today. I haven't tested them, but I believe a number of the newer Dell systems already have the required northbridge code in flash. tboot will use the binary northbridge setup blob that may be passed to it or it will try to use any blobs built into the flash if it isn't given a blob by grub. In the case that it doesn't have the magic blob needed to set up the CPU and northbridge it just won't execute the magic SENTER instruction. magic!
However, this is the kind of feature that has a pretty significant impact on the distribution as a whole.
I actually think this is completely wrong. It shouldn't have ANY distro wide impact at all.
Fesco decided that we should probably have a broader discussion about the topic. The most obvious issues are finding a sensible way to incorporate this into Anaconda, but it's also then necessary to make sure that bootloader configuration is updated appropriately.
Agreed. These are exactly the parts that they need to do development. Anaconda shouldn't really need changes, tboot is just a package that needs installed. I'm not sure why that's even a part of the feature request. If anaconda creates the initial grub.conf it might need some work but that is the same issue as the next question. Grubby is what needs discussion and new code. It will need to detect tboot is installed and handle new grub type entries correctly. I haven't seen any code for this, but handling new formats of grub entries is what is really needed here.
Outside that, is there any other impact?
There shouldn't be. Mind you if you want this to be useful for something it's going to take more steps and layers on top, but just booting into a measured launch environment should require no other steps.
Does tboot perform any verification of the kernels, and if so how is that configured?
tboot does no such thing. By default tboot and the Intel Trusted Execution Technology do nothing but measure and record information in a reliable, immutable, verifiable way. If one were to create and install a launch control policy into their own TPM (using the lcp tools) then that policy would be enforced at boot. But this is not and should not be a part of this feature request. The TPM key management required to update the lcp on kernel update just doesn't exist today in a practical way. Instead what we get from this is that tboot will 'measure', aka take a cryptographic hash of the kernel and initrd, and put those into the TPM before it launches the kernel. Thus after the kernel starts there is a method to verify that the hardware was in a known safe state and to verify what the kernel's hash was at launched.
Is the expectation that an install configured with TXT will only boot trusted kernels,
NO NO NO NO NO. ANY mechanism that prevents users from using their own system will require MANUAL intervention on the part of the user. It's possible to build such a box yourself, but If such a change is ever suggested it should (and will be immediately by me) rejected.
and if so what mechanism is used to verify the kernel?
tboot + the Intel Trusted Execution Technology hardware are what's used to measure and launch the kernel. If a launch control policy is configured it will be used to decide if such a kernel should be launched. But there is NO way we should (or even could) EVER automatically create an lcp.
Is there any further integration work that has to be performed for this to be useful?
So much you cannot imagine :) At the moment they are just try to get a system which is capable of measuring itself. We already have kernel functionality which can measure any files being accessed, but we have no way to know what kernel was launched? What good is a list of files if you can't trust the guy creating that list? This gets us that last step, we have a way to know the state of the system and the cryptographic hash representing the contents of the kernel (and initrd) which was launched. We don't have a way to USE this data. Red Hat has some long term goals on how to use this functionality in the enterprise and the gov't has some ideas how to use it in their super secret intelligence world.
Nothing about this should be a default. Nothing about this should affect users who don't turn it on. Nothing about this should lock people out of their own computers.
Does this help?
-Eric
On Wed, 2011-06-22 at 21:55 -0400, Eric Paris wrote:
On 06/22/2011 03:02 PM, Matthew Garrett wrote:
http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed feature for F16. We've traditionally had a hard objection to the functionality because it required either the distribution or downloading of binary code that ran on the host CPU, but it seems that there'll shortly be systems that incorporate the appropriate sinit blob in their BIOS, which is a boundary we've traditionally been fine with.
Such systems supposedly exist today. I haven't tested them, but I believe a number of the newer Dell systems already have the required northbridge code in flash. tboot will use the binary northbridge setup blob that may be passed to it or it will try to use any blobs built into the flash if it isn't given a blob by grub. In the case that it doesn't have the magic blob needed to set up the CPU and northbridge it just won't execute the magic SENTER instruction. magic!
However, this is the kind of feature that has a pretty significant impact on the distribution as a whole.
I actually think this is completely wrong. It shouldn't have ANY distro wide impact at all.
Fesco decided that we should probably have a broader discussion about the topic. The most obvious issues are finding a sensible way to incorporate this into Anaconda, but it's also then necessary to make sure that bootloader configuration is updated appropriately.
Agreed. These are exactly the parts that they need to do development. Anaconda shouldn't really need changes, tboot is just a package that needs installed. I'm not sure why that's even a part of the feature request. If anaconda creates the initial grub.conf it might need some work but that is the same issue as the next question. Grubby is what needs discussion and new code. It will need to detect tboot is installed and handle new grub type entries correctly. I haven't seen any code for this, but handling new formats of grub entries is what is really needed here.
Outside that, is there any other impact?
There shouldn't be. Mind you if you want this to be useful for something it's going to take more steps and layers on top, but just booting into a measured launch environment should require no other steps.
So to recap this for the next FESCo meeting(s).
1. There exists hardware that does not require any binary blobs to be downloaded or distributed within Fedora. 2. The feature does not have any substantial negative impact on the rest of the distribution (apart from requiring some integration work from grubby and anaconda maintainers). 3. What's really missing is the agreement between tboot, anaconda, and grubby maintainers on how to integrate the trusted boot into grubby and anaconda.
Is that correct?
Matthew Garrett <mjg59 <at> srcf.ucam.org> writes:
... http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed feature for F16. ...
Hi,
there will be some posts on Fedora users and testers lists, so please take a look.
http://lists.fedoraproject.org/pipermail/users/2011-June/400539.html
http://lists.fedoraproject.org/pipermail/test/2011-June/100976.html
In the meantime, I got access to this mailing list, so all is well :-)
I have done some inventory on this topic, and have some questions.
The Intel Trusted Platform consists of two components: - Trusted Platform Module (TPM) chip A hardware component, consisting of cryptographic processor and secure memory. - Trusted Boot A software component, open-source and partially close-source (?) components, in Fedora packages. # yum install tboot Installing: tboot i686 20110429-1.fc15 fedora 355 k Installing for dependencies: trousers i686 0.3.6-1.fc15 fedora 279 k
Trusted Boot is a mechanism by which a pre-kernel/VMM module (that uses Intel Trusted Execution Technology (Intel TXT)) performs a measured (pre-identified) and verified launch of an OS kernel/VMM.
First, the obvious questions.
Why do you need Trusted Boot mechanism to ensure that identified and origin- verified Linux kernel is booted ? Why signing a kernel (a la GPG) is not good enough to verify its origin at boot time ?
Now, regarding the Trusted Boot solution.
The obvious question: why does an open-source distro like Fedora (but also Red Hat) want to philosophically accept and technically support this solution ?
Will the TPM allow a third party remote access to the machine ?
Will the TPM be BIOS-configurable (enable/disable) by the user (hardware owner) ? If so, how will that impact the kernel selection in boot process (tboot enable/disable) ?
How is that tboot blob module secured from tampering ? By the virtue of beeing associated with the "root of trust" ?
If the Launch Control Policy can be created and modified by the user, then what prevents an attacker from impersonating the usersysadmin, modifying the policy, and causing a denial-of-boot or unintended-boot attack ?
There is more that this project implements (root of trust, etc).
Ref: tcsd(8) Can that "root of trust" be compromised by TSS applications or any other means (e.g. through tools provided by this project) ?
... Ref: tcsd(8) DEVICE DRIVERS tcsd is compatible with the IBM Research TPM device driver available from http://www.research.ibm.com/gsal/tcpa and the TPM device driver available from http://sf.net/projects/tmpdd
Are these drivers open-source ? Is TPM device driver open-source ?
JB
On Thu, Jun 23, 2011 at 4:21 PM, JB jb.1234abcd@gmail.com wrote:
I have done some inventory on this topic, and have some questions.
I'm not really an expert on this... Hopefully someone will correct my mistakes.
Why do you need Trusted Boot mechanism to ensure that identified and origin- verified Linux kernel is booted ? Why signing a kernel (a la GPG) is not good enough to verify its origin at boot time ?
The TPM allows verifying that this kernel (and only this kernel) is actually running. An attacker with access to the hard drive ("evil maid") can modify the code to disable any signature check that would be done in software (e.t. inside grub); TPM cannot be bypassed this way.
Now, regarding the Trusted Boot solution.
The obvious question: why does an open-source distro like Fedora (but also Red Hat) want to philosophically accept and technically support this solution ?
All a properly deployed TPM does is, it verifies that a specific software is running on the system, and if so, it allows the OS to use some cryptographic keys stored inside the TPM. This could be used for various things - yes, one of them is DRM. Something more useful is only allowing a computer into the "secure" company network after the TPM has testified that it does not have a rootkit running.
Note that none the keys in TPM are not pre-loaded by any distrusted software company - each TPM generates its own keys.
Also note that the TPM does not, itself, stop any software from running, or disconnect anything from a network, and so on - this needs to be done outside of the TPM, using mechanisms that (mostly) already exist anyway (e.g. a network switch that only connects devices that authenticate with a password).
(From a practical standpoint, AFAICS it would be _much_ easier to set up the network access restriction by an IT department than to set up DRM by a world-wide software vendor - I can't see how would one even start to build the list of allowed configurations of all general-purpose computers, which would be necessary for the DRM.)
Will the TPM allow a third party remote access to the machine ?
Absolutely not.
Will the TPM be BIOS-configurable (enable/disable) by the user (hardware owner) ?
AFAIK it usually is so in existing BIOSes - but if you don't use the TPM, it really doesn't affect anything; it's just like an unused sound card.
How is that tboot blob module secured from tampering ?
It is signed by the CPU/TPM manufacturer (Intel in this case).
By the virtue of beeing associated with the "root of trust" ?
"Root of trust" in TPM lingo is something different - it's "we know that the kernel and related software we run has not been tampered with". The root of trust is established by the tboot blob, which should verify the state of all relevant hardware.
If the Launch Control Policy can be created and modified by the user, then what prevents an attacker from impersonating the usersysadmin, modifying the policy, and causing a denial-of-boot or unintended-boot attack ?
I'm not sure whether it is actually possible to set up LCP so that the boot doesn't continue at all. Assuming that it is so...
1) If the LCP did not require a signed kernel, and the attacker has modified it to require a signed kernel, this is not really different from an attacker deleting /boot. If an attacker has root access, denial of service is the smallest of your problems.
2) If the LCP required a signed kernel, and the attacker has somehow managed to configure the system to boot a different kernel (without getting complete root access), then "denial of boot" would be considered a success - the policy has worked exactly as the sysadmin configured it.
The big question here is kernel upgrades - there has to be a mechanism to replace the old "allowed" kernel by a newer version, and I don't know how that is supposed to work. And assuming an attacker with root access, it might be possible for the attacker to use this upgrade mechanism to let the system boot a modified kernel without violating the LCP.
DEVICE DRIVERS tcsd is compatible with the IBM Research TPM device driver available from http://www.research.ibm.com/gsal/tcpa and the TPM device driver available from http://sf.net/projects/tmpdd
Are these drivers open-source ? Is TPM device driver open-source ?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=dr... seems to contain a few open-source drivers for the hardware. AFAIK none of the required drivers are binary-only. Mirek
Miloslav Trmač <mitr <at> volny.cz> writes:
On Thu, Jun 23, 2011 at 4:21 PM, JB <jb.1234abcd <at> gmail.com> wrote: ...
Will the TPM allow a third party remote access to the machine ?
Absolutely not.
You are wrong here.
http://en.wikipedia.org/wiki/Trusted_Platform_Module "... Overview ... It also includes capabilities such as remote attestation ..."
Also: http://lists.fedoraproject.org/pipermail/users/2011-June/400545.html
...
By the virtue of beeing associated with the "root of trust" ?
"Root of trust" in TPM lingo is something different - it's "we know that the kernel and related software we run has not been tampered with". The root of trust is established by the tboot blob, which should verify the state of all relevant hardware.
There is more to that. With regard to "root of trust" origin, meaning, applications:
1. OS privilege isolation
http://communities.intel.com/community/openportit/vproexpert/blog/2011/01/25... "... Who remembers the ring hierarchy introduced on the 286 that allowed creating an operating system with privilege isolation? ... Trusted Execution Technology (TXT) comes as a reinforcement to deal with threats that act on the same level of the kernel operating system or even more privileged levels -- like hypervisor’s malware, where the malicious code can take advantage of the CPU virtualization instructions to emulate hardware instructions and completely control the operating system. ..."
2. platform integrity (hardware plus software) http://en.wikipedia.org/wiki/Trusted_Platform_Module "... Platform Integrity ... In this context "integrity" means "behave as intended" and a "platform" is generically any computer platform - not limited to PCs or just Windows ... ... Together with the BIOS, the TPM forms a Root of Trust: ... ..."
3. DRM; Software Licensing. http://en.wikipedia.org/wiki/Trusted_Platform_Module "... Other uses and concerns Almost any encryption-enabled application can in theory make use of a TPM, including: Digital rights management Software license protection & enforcement ..."
...
JB
Miloslav TrmaÄ <mitr <at> volny.cz> writes:
On Thu, Jun 23, 2011 at 4:21 PM, JB <jb.1234abcd <at> gmail.com> wrote: ...
Will the TPM allow a third party remote access to the machine ?
Absolutely not.
You are wrong here.
http://en.wikipedia.org/wiki/Trusted_Platform_Module "... Overview ... It also includes capabilities such as remote attestation ..."
Also: http://lists.fedoraproject.org/pipermail/users/2011-June/400545.html
So how do we ensure that software is not leveraging this by default and is user-auditable?
...
By the virtue of beeing associated with the "root of trust" ?
"Root of trust" in TPM lingo is something different - it's "we know that the kernel and related software we run has not been tampered with". The root of trust is established by the tboot blob, which should verify the state of all relevant hardware.
There is more to that. With regard to "root of trust" origin, meaning, applications:
- OS privilege isolation
http://communities.intel.com/community/openportit/vproexpert/blog/2011/01/25... "... Who remembers the ring hierarchy introduced on the 286 that allowed creating an operating system with privilege isolation? ... Trusted Execution Technology (TXT) comes as a reinforcement to deal with threats that act on the same level of the kernel operating system or even more privileged levels -- like hypervisorâs malware, where the malicious code can take advantage of the CPU virtualization instructions to emulate hardware instructions and completely control the operating system. ..."
- platform integrity (hardware plus software) http://en.wikipedia.org/wiki/Trusted_Platform_Module "... Platform Integrity ... In this context "integrity" means "behave as intended" and a "platform" is generically any computer platform - not limited to PCs
or just Windows ... ... Together with the BIOS, the TPM forms a Root of Trust: ... ..."
- DRM; Software Licensing. http://en.wikipedia.org/wiki/Trusted_Platform_Module "... Other uses and concerns Almost any encryption-enabled application can in theory make use of a
TPM, including: Digital rights management Software license protection & enforcement ..."
...
JB
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Jun 23, 2011 at 7:30 PM, JB jb.1234abcd@gmail.com wrote:
Miloslav Trmač <mitr <at> volny.cz> writes:
On Thu, Jun 23, 2011 at 4:21 PM, JB <jb.1234abcd <at> gmail.com> wrote: ...
Will the TPM allow a third party remote access to the machine ?
Absolutely not.
You are wrong here.
http://en.wikipedia.org/wiki/Trusted_Platform_Module "... Overview ... It also includes capabilities such as remote attestation ..."
"Remote attestation" doesn't mean "remote access" - after all, the TPM does not contain a network card and it cannot connect an Ethernet cable to the socket in the wall :)
The TPM support for remote attestation amounts to "if the system was measured as expected, produce a signature to that effect, and produce a signature to other data the system has produced for this purpose" ("other data" being e.g. the result of an additional self-check of the sistem). What TPM does is a purely local operation. Whether and how this ends up on a remote system and whether and how is is used by the remote system, is a matter of pure software that doesn't need the TPM for anything else.
TPM doesn't "allow" a third party remote access any more than a CPU that is strong enough to let you run ssh on it. Mirek
On Thu, Jun 23, 2011 at 7:30 PM, JB jb.1234abcd@gmail.com wrote:
Miloslav TrmaÄ <mitr <at> volny.cz> writes:
On Thu, Jun 23, 2011 at 4:21 PM, JB <jb.1234abcd <at> gmail.com> wrote: ...
Will the TPM allow a third party remote access to the machine ?
Absolutely not.
You are wrong here.
http://en.wikipedia.org/wiki/Trusted_Platform_Module "... Overview ... It also includes capabilities such as remote attestation ..."
"Remote attestation" doesn't mean "remote access" - after all, the TPM does not contain a network card and it cannot connect an Ethernet cable to the socket in the wall :)
The TPM support for remote attestation amounts to "if the system was measured as expected, produce a signature to that effect, and produce a signature to other data the system has produced for this purpose" ("other data" being e.g. the result of an additional self-check of the sistem). What TPM does is a purely local operation. Whether and how this ends up on a remote system and whether and how is is used by the remote system, is a matter of pure software that doesn't need the TPM for anything else.
TPM doesn't "allow" a third party remote access any more than a CPU that is strong enough to let you run ssh on it.
Exactly. But with the network card, the process by which I can activate, deactivate, control and monitor that device to allow or deny access is well documented. How will are those things done with TPM? I want to know that even if someone slips a TPM-exploiting backdoor into my system, I know that it won't have an effect because cat /proc/foo/bar/tpm returns 0.
How does this work?
-J
Mirek-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
JB <jb.1234abcd <at> gmail.com> writes:
http://en.wikipedia.org/wiki/Trusted_computing
TC is controversial because it is technically possible not just to secure the hardware for its owner, but also to secure against its owner. Such controversy has led opponents of trusted computing, such as Richard Stallman, to refer to it instead as treacherous computing, even to the point where some scholarly articles have begun to place quotation marks around "trusted computing".
JB
On 06/24/2011 12:55 PM, JB wrote:
JB <jb.1234abcd <at> gmail.com> writes:
http://en.wikipedia.org/wiki/Trusted_computing
TC is controversial because it is technically possible not just to secure the hardware for its owner, but also to secure against its owner. Such controversy has led opponents of trusted computing, such as Richard Stallman, to refer to it instead as treacherous computing, even to the point where some scholarly articles have begun to place quotation marks around "trusted computing".
If you have *specific* concerns, let's hear those. You seem to just quoting parts of a public wiki page anyone can read. I don't see the point of that
Rahul
On Fri, Jun 24, 2011 at 4:07 AM, Rahul Sundaram metherid@gmail.com wrote:
If you have *specific* concerns, let's hear those. You seem to just quoting parts of a public wiki page anyone can read. I don't see the point of that
If trusted boot in fedora is widely deployed, then $random_things may demand I use a particular fedora kernel in order to access them. Both handcapping my personal freedom to tinker with my own computer by imposing new costs on it, and hampering the Fedora project by creating additional friction against upgrades. ("Sorry, I can't upgrade to the new kernel to test that, because then I won't be able to watch netflicks!")
In cases where remote attestation is especially important for legitimate purposes then it would be completely acceptable to require the user to enable it. Making it work by default will encourage the use of the functionality in places where it is not important, because the community of tinkerers and innovators is simply small enough to ignore.
Is that the world we want to live in? Why should our project contribute to that world's creation?
I think the wide (e.g. by default) deployment of remote attestation undermines the Fedora foundational value of freedom and will inhibit the innovation which is central to the project's mission. Accordingly, support for remote attestation in the default install should be explicitly and categorically rejected with the same vigor, and many of the same reasons, that the project rejects proprietary software which it could lawfully distribute.
I am still struggling to see real applications for this. I don't know how a networked system using the technology could be differentiated from an (insecure) software simulation of the same from a remote viewer's perspective. Also I don't see how it would be used in the world of servers where virtualisation is the way the world is going. I can imagine some limited application in an appliance, but only if the system was end-to-end secured, with a trusted kernel that only runs signed binaries and those binaries only running signed plugins, for example to play content locked material. While that is something that could feasibly be built with open source software, it's not something I imagine most users would be interested in.
-Cam
On Fri, Jun 24, 2011 at 10:01:45AM +0100, Camilo Mesias wrote:
I am still struggling to see real applications for this. I don't know how a networked system using the technology could be differentiated from an (insecure) software simulation of the same from a remote viewer's perspective. Also I don't see how it would be used in the
Afaik it would allow to securely enter hard disk encryption passwords via network on a Fedora system, because one can ensure that the correct (untampered) initrd / kernel is loaded. You cannot simulate this afaik because the used cryptographic keys are only stored in the TPM module and cannot be accessed from the outside. Therefore one needs to tamper with the TPM module instead of only with the unencrypted /boot partition, which is a lot harder from my point of view.
Regards Till
On Fri, Jun 24, 2011 at 10:01:45AM +0100, Camilo Mesias wrote:
I am still struggling to see real applications for this. I don't know how a networked system using the technology could be differentiated from an (insecure) software simulation of the same from a remote viewer's perspective. Also I don't see how it would be used in the
Afaik it would allow to securely enter hard disk encryption passwords via network on a Fedora system, because one can ensure that the correct (untampered) initrd / kernel is loaded. You cannot simulate this afaik because the used cryptographic keys are only stored in the TPM module and cannot be accessed from the outside. Therefore one needs to tamper with the TPM module instead of only with the unencrypted /boot partition, which is a lot harder from my point of view.
So you can't possibly duplicate the keys elsewhere and modify the software calling them to look in that place, allowing you to virtualize a whole cluster of the same "trusted" machine?
-J
Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, Jun 24, 2011 at 1:21 PM, Jon Ciesla limb@jcomserv.net wrote:
On Fri, Jun 24, 2011 at 10:01:45AM +0100, Camilo Mesias wrote:
I am still struggling to see real applications for this. I don't know how a networked system using the technology could be differentiated from an (insecure) software simulation of the same from a remote viewer's perspective. Also I don't see how it would be used in the
Afaik it would allow to securely enter hard disk encryption passwords via network on a Fedora system, because one can ensure that the correct (untampered) initrd / kernel is loaded. You cannot simulate this afaik because the used cryptographic keys are only stored in the TPM module and cannot be accessed from the outside. Therefore one needs to tamper with the TPM module instead of only with the unencrypted /boot partition, which is a lot harder from my point of view.
So you can't possibly duplicate the keys elsewhere and modify the software calling them to look in that place, allowing you to virtualize a whole cluster of the same "trusted" machine?
I think I can imagine how it might work - assuming that each device has unique key material, you could do cryptographic operations that ensure that the device you are talking to still has the same key (without exposing the key). So you infer the identity of the device you are talking to is that expected (ie the same device and not a replacement). This would enable a booting client to request disk passwords from a server after ensuring that the server is the one it is configured to recognise. The server would also be able to give the keys to the client, knowing that it was the genuine client and not an impostor.
You could implement the whole thing in software, but the point is the key material is stored securely, so could not be copied in the same way you could take a copy of a private key stored in a filesystem.
The other way for this to be used would be for the device to have non-unique material - ie. a 'ChipCorp' key - that is the same in many devices. Then external entities would be able to challenge a device to sign something with that key and verify that the device was a 'genuine' one. You would be unable to implement this in software unless you knew the secret stored inside the device.
-Cam
On Fri, 2011-06-24 at 11:11 +0200, Till Maas wrote:
On Fri, Jun 24, 2011 at 10:01:45AM +0100, Camilo Mesias wrote:
I am still struggling to see real applications for this. I don't know how a networked system using the technology could be differentiated from an (insecure) software simulation of the same from a remote viewer's perspective. Also I don't see how it would be used in the
Afaik it would allow to securely enter hard disk encryption passwords via network on a Fedora system, because one can ensure that the correct (untampered) initrd / kernel is loaded. You cannot simulate this afaik because the used cryptographic keys are only stored in the TPM module and cannot be accessed from the outside. Therefore one needs to tamper with the TPM module instead of only with the unencrypted /boot partition, which is a lot harder from my point of view.
And as time passes and weaknesses are exposed in the encryption scheme hard-wired into the TPM component, what do we do then other than buy new hardware in a panic? (Assuming this becomes a technology we all come to depend on in some way and doesn't just sort of die off in the commercial space as I expect it will.)
There is nothing preventing smart people from being smart and this is why hard-wired crypto solutions are always of both extremely short usefulness (you have to buy a new $device to either change compromised keys or upgrade to higher security) and under enhanced threat due to their value as slow-moving security targets for attackers. The best middle-ground solution I've seen is to involve a hardware device such as an IC Card/SmartCard/dongle that is easily expendable/removable/cheap in the solution so the major components do not themselves become expendable.
This is the direction the government and military are coming from -- viewing crypto components as expendable -- because they are always subject to attack. Either the TPM and stored hashes are removable or the entire computing system has an extremely short lifecycle duration. They are interested in the technology, but the flavor of their interest is different than the commercial DRM vendor space -- and I don't see any other driving interest in the commercial space than this. The commercial space has a significantly different take on things and also an overwhelming underestimation of how effective the wild unwashed masses are at producing circumvention to such technologies when given sufficient reason (and anything is a good reason to some people).
But we already have SmartCard, dongle, etc. solutions and their usefulness extends to where they are used today. How is TPM any different other than it is inextricably tied to the rest of my computer and now my computer can be regulated? Simply guaranteeing that a certain kernel was booted guarantees nothing -- a proper kernel can still be the platform for sinister activity. And anyway, hashing and verifying the hash of the kernel can be done in other, removable (and device independent) ways than hardwiring the solution into the computer.
If I want to use the same computer for 5 years, but someone either cracks the algorythm behind the encryption used or finds a repository of generated keys (or even just a slight weakness in the randomness of generated keys, thus massively reducing the set of actual vs theoretical keys) what am I to do? I like netflix and want to keep watching, but the chipset I have is no longer acceptable under their EUA, so I have to buy new hardware that I don't want or otherwise need. Currently this happens with forced Windows upgrades and we all rail against that. Now it can happen on a different level because we are introducing a new layer of "hardware requirements" and one that can be as strictly enforced as it can be arbitrary.
Those are my concrete concerns and I don't see how hardwiring what is essentially a mathematical solution to a problem is the right direction from a technical standpoint in the consumer space. In fact, historically speaking this is a direct step back away from fully programmable information processing systems, because we are hardwiring security components into the system now. This sounds like a 1950's solution in need of a 2010's problem.
The dream (or rather the public sales pitch) is that with TPM we can leave laptops unattended for extended periods in hotel rooms and not be subject to evil maid attacks because the system will verify itself in a way that can't be overwritten by the maid. But this is silly. If you lose control of the device what is to prevent said evil maid from simply swapping your processor or tampering in other ways with the hardware (after all, the tboot protocol is already described as skipping the check if a non-TXT enabled device is present)?
It didn't take long for iPhone hackers to find nifty solutions to their perceived problems, I can't imagine professional security crackers will not come up with similar solutions in a jiffy. We will never escape the cardinal rule of security that if an attacker has physical access then you do not have security. There is a reason that is beaten into the heads of new security students. Imagining otherwise is a pipe dream, and has been so proven since the 40's. In fact, this sounds a lot to me like one of the scenarios where a hardware promise winds up delivering an even worse vulnerability from an unexpected angle later.
The technology will be cracked. Each generation of TPM will be cracked. All encryption is based on decaying standards. The consortium required to make a decision on an awkward false standard like trusted computing will never be able to react fast enough to the reality that somewhere out there there is always someone smarter than whoever made the TPM (and considering that comittee logic tends to produce lowest-common-denominator tecnology/decisions anyway, this is likely), so the TPM producers will always be engaged in a losing race.
Consider the state of hardware hacking in the gaming console gaming community -- and that is just for video games. The game console hackers are not very numerous, and yet have met with great success (and great litigation from time to time -- but suing your own best customers is another issue altogether). Consider how many more people will have a vested interest in crushing $current_tpm_standard if it is a core component of general purpose computers and how many more people will beleive the story they are sold about how secure it makes everything (and the inveitable slew of terrible security mistakes that will ensue as a result of the droves of tech-ignorant masses relying on just one layer of hardwired security).
DRM only really prevents fair-use copies, as there is always a workaround for human-use media and there is nothing that can be done about it. Market models have to change, not my computer's boot cycle, because of the new realities of the consumer space.
All that being said -- aside from:
1. Government/military use in environments where 1 year is a long time to be using the same device 2. DRM schemes which open the door to regulation of the sale of non-TPM devices [1]
what are the uses of this technology that do not already have well understood solutions? Secure login has a hundred schemes, many of the quite good. Is TPM so groundbreaking that it stands a shot at permanently replacing such mechanisms? If not, then I do not think it is reasonable to permanently install TPM components in my computer.
These are the things we should be discussing in a general sense, in my view, not just the technicals of implementation. Software is wonderful at making boolean determinations, and so tboot naturally can be made to not interfere with people who don't have a TPM. This is not a hard question. The problems are societal and practical in nature. Societally speaking the FOSS community stands pretty resolutely against patent encumberance and DRM. As a practical measure it simply does not make sense to hardwire a cryptographic solution into a long-term general use piece of hardware.
-Iwao
[1] This opens the door to regulating the sale or possession of non-DRM devices such as cameras, phones, computers, whatever -- and before you think this is preposterous, consider that there are already laws against disabling, say, region coding technology on an old DVD player despite the fact that you own the device (which begs the question: Can it be made illegal to change your own oil filter?)
On Fri, Jun 24, 2011 at 11:01 AM, Camilo Mesias camilo@mesias.co.uk wrote:
I don't know how a networked system using the technology could be differentiated from an (insecure) software simulation of the same from a remote viewer's perspective.
The attestation is signed by a key that cannot be extracted from the TPM.
Also I don't see how it would be used in the world of servers where virtualisation is the way the world is going.
I suppose one would have to first authenticate the hypervisor, and then rely on it to help authenticate the guests.
I can imagine some limited application in an appliance, but only if the system was end-to-end secured, with a trusted kernel that only runs signed binaries and those binaries only running signed plugins, for example to play content locked material. While that is something that could feasibly be built with open source software, it's not something I imagine most users would be interested in.
An oVirt node (a tiny-footprint hypervisor appliance) fits this description exactly. Mirek
fre 2011-06-24 klockan 10:01 +0100 skrev Camilo Mesias:
I am still struggling to see real applications for this. I don't know how a networked system using the technology could be differentiated from an (insecure) software simulation of the same from a remote viewer's perspective.
Add another requirement: The remote viewer has previously had the opportunity to locally/physically inspect the device and determine what public key it has generated.
/abo
On Fri, Jun 24, 2011 at 10:24 AM, Gregory Maxwell gmaxwell@gmail.com wrote:
If trusted boot in fedora is widely deployed, then $random_things may demand I use a particular fedora kernel in order to access them.
I can't see how it would make any difference whether Fedora supports the feature or not - after all, any vendor can add patch Fedora to add TPM support and then "$random_things may demand you use a particular vendor-modified Fedora in order to access them" - or a particular non-Fedora operating system, just as well. Mirek
On Fri, 2011-06-24 at 11:10 +0200, Miloslav Trmač wrote:
On Fri, Jun 24, 2011 at 10:24 AM, Gregory Maxwell gmaxwell@gmail.com wrote:
If trusted boot in fedora is widely deployed, then $random_things may demand I use a particular fedora kernel in order to access them.
I can't see how it would make any difference whether Fedora supports the feature or not - after all, any vendor can add patch Fedora to add TPM support and then "$random_things may demand you use a particular vendor-modified Fedora in order to access them" - or a particular non-Fedora operating system, just as well.
Yes, I completely agree. What Gregory tries to emphasis here - as I understand it, of course he might have a different intention - is purely politics and I do not think, that Fedora should involve in political decisions in one way or another.
If the feature conforms to Fedora legal requirements and the developers of the affected packages are OK with integrating necessary patches, it should be allowed.
2011/6/24 Tomas Mraz tmraz@redhat.com:
Yes, I completely agree. What Gregory tries to emphasis here - as I understand it, of course he might have a different intention - is purely politics and I do not think, that Fedora should involve in political decisions in one way or another.
Frankly, I view the DRM issue as somewhat of a red herring in this discussion. I can't see any reasonable way to set up a TPM-based DRM scheme for general-purpose computers: where does the trust come from? If nothing else, there must be thousands of common computer models/configurations; if a client connects to a music shop for the first time, how can the music shop tell the difference between an unmodified computer and a computer modified to record the music files?
A company's IT department can install the computer from scratch by a trusted employee, "measure" the system, record the results, and use that as a baseline for the future use of the TPM within for attestation that company.
A maker of an entertainment console can do something similar before it ships the device to customers.
But for a general-purpose computer designed by a third party, I really can't see the trust mechanism. Mirek
On Fri, 2011-06-24 at 11:41 +0200, Miloslav Trmač wrote:
2011/6/24 Tomas Mraz tmraz@redhat.com:
Yes, I completely agree. What Gregory tries to emphasis here - as I understand it, of course he might have a different intention - is purely politics and I do not think, that Fedora should involve in political decisions in one way or another.
Frankly, I view the DRM issue as somewhat of a red herring in this discussion. I can't see any reasonable way to set up a TPM-based DRM scheme for general-purpose computers: where does the trust come from? If nothing else, there must be thousands of common computer models/configurations; if a client connects to a music shop for the first time, how can the music shop tell the difference between an unmodified computer and a computer modified to record the music files?
A company's IT department can install the computer from scratch by a trusted employee, "measure" the system, record the results, and use that as a baseline for the future use of the TPM within for attestation that company.
A maker of an entertainment console can do something similar before it ships the device to customers.
But for a general-purpose computer designed by a third party, I really can't see the trust mechanism. Mirek
Perhaps you just answered your own question in reverse.
Have you considered that the real goal could easily be to exclude third-parties?
-Iwao
2011/6/24 Tomas Mraz tmraz@redhat.com:
On Fri, 2011-06-24 at 11:10 +0200, Miloslav Trmač wrote:
On Fri, Jun 24, 2011 at 10:24 AM, Gregory Maxwell gmaxwell@gmail.com wrote:
If trusted boot in fedora is widely deployed, then $random_things may demand I use a particular fedora kernel in order to access them.
I can't see how it would make any difference whether Fedora supports the feature or not - after all, any vendor can add patch Fedora to add TPM support and then "$random_things may demand you use a particular vendor-modified Fedora in order to access them" - or a particular non-Fedora operating system, just as well.
The userbase of Fedora as a whole is substantially larger than the userbase of fedora users who run non-default kernels. The small benefit of mandatory remote attestation could be far more easily outweighed by the loss of the whole Fedora userbase than it could be outweighed by the loss of the tiny subset of the Fedora users who are actively practicing the freedom's theoretically provided by Fedora (and wouldn't simply stop if the freedom was made costly by a restriction).
[I can make clear examples of cases where large relevant internet resources chose to exclude userbases larger than Fedora-users-with-modified kernels for just slight convenience, but took inconvenience to support ones comparable in size to Fedora, but I'm trying to stay scrupulously on-topic]
Yes, I completely agree. What Gregory tries to emphasis here - as I understand it, of course he might have a different intention - is purely politics and I do not think, that Fedora should involve in political decisions in one way or another.
If the feature conforms to Fedora legal requirements and the developers of the affected packages are OK with integrating necessary patches, it should be allowed.
I'm puzzled by this response. Would you also support Fedora packaging and distributing proprietary binary only applications offered under a license which legally allows Fedora to do so, but which disallowed the end user the freedom to modify and understand the software? How is this also not equally political?
The Fedora project has a specific mission with numerous points around software innovation which is grounded on a set of foundational principles with include the users freedom. A likely end result of the default inclusion of this functionality will degrade these goals. (And if you do not think that remote attestation will ever be used to regulate access as has been proposed here, what do you intend to use it for?)
Personally, I think it is of greater practical concern to me that I retain the ability to have equal functionality via my system no matter if I run a non-standard kernel or not, more practically important that if fedora ships a few binary-only applications here and there.
More technically, can the software be modified to refuse to disclose the signature which links the chip specific TPM key to any third party TPM trust root? If this were not disclosed the functionality could not be used for third party attestation, but e.g. users could still use it to make sure a root kit had not been installed on one of their systems before remotely providing keys because they could simply remember their hardware's keys rather than validating them against the manufacturers keys, but a third party that wanted to deny access to non-standard fedora configurations would have no way to know if the attestation were authentic. Users could still boot into a special modified kernel to obtain that linkage, but I believe the simple roadblock of not making it available by default would address my concerns.
On Fri, 2011-06-24 at 09:43 -0400, Gregory Maxwell wrote:
2011/6/24 Tomas Mraz tmraz@redhat.com:
On Fri, 2011-06-24 at 11:10 +0200, Miloslav Trmač wrote:
On Fri, Jun 24, 2011 at 10:24 AM, Gregory Maxwell gmaxwell@gmail.com wrote:
If trusted boot in fedora is widely deployed, then $random_things may demand I use a particular fedora kernel in order to access them.
I can't see how it would make any difference whether Fedora supports the feature or not - after all, any vendor can add patch Fedora to add TPM support and then "$random_things may demand you use a particular vendor-modified Fedora in order to access them" - or a particular non-Fedora operating system, just as well.
The userbase of Fedora as a whole is substantially larger than the userbase of fedora users who run non-default kernels. The small benefit of mandatory remote attestation could be far more easily outweighed by the loss of the whole Fedora userbase than it could be outweighed by the loss of the tiny subset of the Fedora users who are actively practicing the freedom's theoretically provided by Fedora (and wouldn't simply stop if the freedom was made costly by a restriction).
[I can make clear examples of cases where large relevant internet resources chose to exclude userbases larger than Fedora-users-with-modified kernels for just slight convenience, but took inconvenience to support ones comparable in size to Fedora, but I'm trying to stay scrupulously on-topic]
Yes, I completely agree. What Gregory tries to emphasis here - as I understand it, of course he might have a different intention - is purely politics and I do not think, that Fedora should involve in political decisions in one way or another.
If the feature conforms to Fedora legal requirements and the developers of the affected packages are OK with integrating necessary patches, it should be allowed.
I'm puzzled by this response. Would you also support Fedora packaging and distributing proprietary binary only applications offered under a license which legally allows Fedora to do so, but which disallowed the end user the freedom to modify and understand the software? How is this also not equally political?
Oops I might not be clear enough in my response. With the "Fedora legal requirements" I meant not only the restrictions what can Fedora ship as allowed by laws of countries where Fedora is shipping but also the basic restriction that Fedora imposed upon itself within its roots and that is to provide only fully open source non-proprietary software (let's not dive into the firmware blobs issues now, please).
And if trusted boot does not break this core requirement I think it should be allowed within Fedora.
On 06/24/2011 03:24 AM, Gregory Maxwell wrote:
On Fri, Jun 24, 2011 at 4:07 AM, Rahul Sundaram metherid@gmail.com wrote:
If you have *specific* concerns, let's hear those. You seem to just quoting parts of a public wiki page anyone can read. I don't see the point of that
If trusted boot in fedora is widely deployed, then $random_things may demand I use a particular fedora kernel in order to access them. Both handcapping my personal freedom to tinker with my own computer by imposing new costs on it, and hampering the Fedora project by creating additional friction against upgrades. ("Sorry, I can't upgrade to the new kernel to test that, because then I won't be able to watch netflicks!")
Would it be possible or practical to ship tboot in Fedora with the user-serving protections enabled - verifying the kernel/initrd for secure disk encryption, for instance - but disabling remote attestation and similar features in the default configuration?
If there's a way that I can harness the TPM to ensure the integrity of my boot path - and it is sufficiently transparent that I am confident of what it is doing, and can build and sign my own kernels if desired - I would be interested in that. However, I appreciate (and largely agree with) Gregory's concerns about being an enabler for a broader restricted computing ecosystem.
- Michael
On 06/24/2011 04:07 AM, Rahul Sundaram wrote:
On 06/24/2011 12:55 PM, JB wrote:
JB <jb.1234abcd <at> gmail.com> writes:
http://en.wikipedia.org/wiki/Trusted_computing
TC is controversial because it is technically possible not just to secure the hardware for its owner, but also to secure against its owner. Such controversy has led opponents of trusted computing, such as Richard Stallman, to refer to it instead as treacherous computing, even to the point where some scholarly articles have begun to place quotation marks around "trusted computing".
If you have *specific* concerns, let's hear those. You seem to just quoting parts of a public wiki page anyone can read. I don't see the point of that
His point is rather obvious really not sure why you're picking on him - many may be unfamiliar with this and he spent time finding out and sharing what others, who have thought about this topic, have to say.
On 06/24/2011 05:38 PM, Genes MailLists wrote:
His point is rather obvious really not sure why you're picking on him
- many may be unfamiliar with this and he spent time finding out and
sharing what others, who have thought about this topic, have to say.
I am not picking on anyone but quoting paragraphs one after another from a wikipedia page in repeated threads isn't conductive to a discussion. Ask any questions and add a reference once. If anyone wants to read further, they can go ahead and read the page directly.
Rahul
On 06/24/2011 04:07 AM, Rahul Sundaram wrote:
On 06/24/2011 12:55 PM, JB wrote:
JB<jb.1234abcd<at> gmail.com> writes:
http://en.wikipedia.org/wiki/Trusted_computing
TC is controversial because it is technically possible not just to secure the hardware for its owner, but also to secure against its owner. Such controversy has led opponents of trusted computing, such as Richard Stallman, to refer to it instead as treacherous computing, even to the point where some scholarly articles have begun to place quotation marks around "trusted computing".
If you have *specific* concerns, let's hear those. You seem to just quoting parts of a public wiki page anyone can read. I don't see the point of that
Rahul
Rahul,
Seems he is using references to support contentions...like a scholarly journal article. With respect, just as you are free to criticize on these mailing lists, he is free to speak on them as long as he follows proper netiquette.
On 06/24/2011 09:55 PM, Clyde E. Kunkel wrote
Rahul,
Seems he is using references to support contentions...like a scholarly journal article. With respect, just as you are free to criticize on these mailing lists, he is free to speak on them as long as he follows proper netiquette.
The proper etiquette would be to use the reference once and state the contention along with it. Not merely copy paste wikipedia article content multiple times in a thread especially when you are confusing remote attestation with remote access. What am I suggesting is a more effective way. and less noise.
Rahul
On 06/24/2011 11:04 AM, Rahul Sundaram wrote:
On 06/24/2011 09:55 PM, Clyde E. Kunkel wrote
Rahul,
Seems he is using references to support contentions...like a scholarly journal article. With respect, just as you are free to criticize on these mailing lists, he is free to speak on them as long as he follows proper netiquette.
The proper etiquette would be to use the reference once and state the contention along with it. Not merely copy paste wikipedia article content multiple times in a thread especially when you are confusing remote attestation with remote access. What am I suggesting is a more effective way. and less noise.
Rahul
OK, you win, Rahul. From now on you will be the Emily Post of mail lists. :-)
Rahul Sundaram <metherid <at> gmail.com> writes:
On 06/24/2011 09:55 PM, Clyde E. Kunkel wrote
Rahul,
Seems he is using references to support contentions...like a scholarly journal article. With respect, just as you are free to criticize on these mailing lists, he is free to speak on them as long as he follows proper netiquette.
The proper etiquette would be to use the reference once and state the contention along with it. Not merely copy paste wikipedia article content multiple times in a thread especially ...
Now you know what it is ...
when you are confusing remote attestation with remote access.
I think you are in over your head ...
What am I suggesting is a more effective way. and less noise.
Exactly, that's all you do ... your thought added value in the thread is zero.
Colorado Cops Arrest Man Who Hid Inside Toilet Tank At Yoga Festival
http://www.thesmokinggun.com/buster/toilet/colorado-toilet-tank-arrest-64903...
JB
...snip...
Can we move this back to technical, Fedora development related discussion?
thanks,
kevin
On Sat, Jun 25, 2011 at 2:04 PM, Kevin Fenzi kevin@scrye.com wrote:
...snip...
Can we move this back to technical, Fedora development related discussion?
I am slightly disappointed with this response, after all, to quote the original message
"Fesco decided that we should probably have a broader discussion about the topic"
I take it you / FESCO have had enough now?
-Cam
On Sat, Jun 25, 2011 at 5:26 PM, Camilo Mesias camilo@mesias.co.uk wrote:
On Sat, Jun 25, 2011 at 2:04 PM, Kevin Fenzi kevin@scrye.com wrote:
...snip...
Can we move this back to technical, Fedora development related discussion?
I am slightly disappointed with this response, after all, to quote the original message
"Fesco decided that we should probably have a broader discussion about the topic"
I read that as a broader technical discussion. As has been mentioned in the thread its not compulsory, it doesn't restrict people from running custom kernels as always and you need to have the appropriate hardware to make use of the feature anyway. I personally welcome the feature. I have hardware that would allow me to use the feature and I would like to know if something other than me modifies my kernel and core environment and to restrict the ability to boot if that is the case so I can verify what has changed.
Peter
On Sat, 25 Jun 2011 17:26:08 +0100 Camilo Mesias camilo@mesias.co.uk wrote:
On Sat, Jun 25, 2011 at 2:04 PM, Kevin Fenzi kevin@scrye.com wrote:
...snip...
Can we move this back to technical, Fedora development related discussion?
I am slightly disappointed with this response, after all, to quote the original message
"Fesco decided that we should probably have a broader discussion about the topic"
I take it you / FESCO have had enough now?
No. I am saying that I personally have had enough of personal attacks and side discussions on quoting styles. :)
I welcome posts back on the technical topic of trusted boot. ;)
kevin
On Sat, 25 Jun 2011 10:41:36 -0600 Kevin Fenzi kevin@scrye.com wrote:
I welcome posts back on the technical topic of trusted boot. ;)
Right.
So can we have specifics about what it's good for? Not how it is implemented, but what the purposes are.
And who the "trusted" entities are (can be) in the chain of trust.
Those sorts of technical topics would be interesting.
kevin
On Sat, Jun 25, 2011 at 12:06 PM, Bernd Stramm bernd.stramm@gmail.com wrote:
On Sat, 25 Jun 2011 10:41:36 -0600 Kevin Fenzi kevin@scrye.com wrote:
I welcome posts back on the technical topic of trusted boot. ;)
Right.
So can we have specifics about what it's good for? Not how it is implemented, but what the purposes are.
And who the "trusted" entities are (can be) in the chain of trust.
Those sorts of technical topics would be interesting.
I agree this would be interesting.
On a more practical level I'd like to hear with more specifics about how this fits the definition of a feature as stated here
http://fedoraproject.org/wiki/Features/Policy/Definitions
Does it meet any of the points 1, 2, or 4?
If it is proposed as a feature based on either or both of points 3 and 5 has marketing or anyone outside of FESCo been involved in deciding whether this meets those requirements from their perspective? I ask this because points 3 and 5 don't seem to be based on anything technical.
John
What I don't understand is why this feature requires a binary blob. Surely whatever northbridge code is required can be free software, Is this just security through obscurity?
Andrew.
Andrew Haley wrote:
What I don't understand is why this feature requires a binary blob. Surely whatever northbridge code is required can be free software, Is this just security through obscurity?
That's a good question. I get the impression that Sinit (as the blob seems to be called) is from Intel. Intel is a hardware company. Selling licenses for unfree software isn't their business model, and they're already involved in writing free drivers for their graphics and wifi chips. If Intel is pushing to have this feature included in Fedora, what prevents them from setting Sinit free?
Björn Persson
On Fri, Jun 24, 2011 at 12:49 PM, Andrew Haley aph@redhat.com wrote:
What I don't understand is why this feature requires a binary blob. Surely whatever northbridge code is required can be free software, Is this just security through obscurity?
The purpose of the blob is to "measure" the system state; only the blob (and hardware reset) is allowed to restart the "measuring" process in the TPM. For this to work securely, the blob must be signed by someone that the TPM itself trusts - otherwise an attacker could replace the blob by something that lies about the system state.
So, from a standpoint of hacking, it doesn't matter - users won't have the practical freedom to modify the blob anyway because they can't sign it.
From a standpoint of learning/sharing/review - I agree having the
source code would be very useful. Mirek
On 24/06/11 20:49, Miloslav Trmač wrote:
On Fri, Jun 24, 2011 at 12:49 PM, Andrew Haley aph@redhat.com wrote:
What I don't understand is why this feature requires a binary blob. Surely whatever northbridge code is required can be free software, Is this just security through obscurity?
The purpose of the blob is to "measure" the system state; only the blob (and hardware reset) is allowed to restart the "measuring" process in the TPM. For this to work securely, the blob must be signed by someone that the TPM itself trusts - otherwise an attacker could replace the blob by something that lies about the system state.
So, from a standpoint of hacking, it doesn't matter - users won't have the practical freedom to modify the blob anyway because they can't sign it.
What we're saying, then, is that the TPM doesn't trust the owner of the computer, but its manufacturer. It's impossible for a user to decide who they trust.
Surely, from a Fedora standpoint, this is a complete non-starter.
Andrew.
On Mon, Jun 27, 2011 at 12:11 PM, Andrew Haley aph@redhat.com wrote:
On 24/06/11 20:49, Miloslav Trmač wrote:
On Fri, Jun 24, 2011 at 12:49 PM, Andrew Haley aph@redhat.com wrote:
What I don't understand is why this feature requires a binary blob. Surely whatever northbridge code is required can be free software, Is this just security through obscurity?
The purpose of the blob is to "measure" the system state; only the blob (and hardware reset) is allowed to restart the "measuring" process in the TPM. For this to work securely, the blob must be signed by someone that the TPM itself trusts - otherwise an attacker could replace the blob by something that lies about the system state.
<snip>
What we're saying, then, is that the TPM doesn't trust the owner of the computer, but its manufacturer. It's impossible for a user to decide who they trust.
First, the TPM (nor the CPU) really can't tell the difference between the owner of the computer and an author of a virus. It's all just software.
Second, every owner of a computer has to completely trust the manufacturer of the computer anyway - there are way too many ways the manufacturer can break the security of the system, e.g. backdoors in the CPU or motherboard, or hidden configurations of https://secure.wikimedia.org/wikipedia/en/wiki/Intel_AMT .
Placing trust in the manufacturer of the hardware puts the user in no worse position than they were before. And the user, of course, still has full control over whether to use the TPM or not, and what to use it for. Mirek
On Mon, 2011-06-27 at 15:12 +0200, Miloslav Trmač wrote:
On Mon, Jun 27, 2011 at 12:11 PM, Andrew Haley aph@redhat.com wrote:
On 24/06/11 20:49, Miloslav Trmač wrote:
On Fri, Jun 24, 2011 at 12:49 PM, Andrew Haley aph@redhat.com wrote:
What I don't understand is why this feature requires a binary blob. Surely whatever northbridge code is required can be free software, Is this just security through obscurity?
The purpose of the blob is to "measure" the system state; only the blob (and hardware reset) is allowed to restart the "measuring" process in the TPM. For this to work securely, the blob must be signed by someone that the TPM itself trusts - otherwise an attacker could replace the blob by something that lies about the system state.
<snip> > What we're saying, then, is that the TPM doesn't trust the owner of > the computer, but its manufacturer. It's impossible for a user to > decide who they trust.
First, the TPM (nor the CPU) really can't tell the difference between the owner of the computer and an author of a virus. It's all just software.
Second, every owner of a computer has to completely trust the manufacturer of the computer anyway - there are way too many ways the manufacturer can break the security of the system, e.g. backdoors in the CPU or motherboard, or hidden configurations of https://secure.wikimedia.org/wikipedia/en/wiki/Intel_AMT .
Placing trust in the manufacturer of the hardware puts the user in no worse position than they were before. And the user, of course, still has full control over whether to use the TPM or not, and what to use it for.
Trusting the manufacturer to not put bugs/backdoors is one thing. Having to depend on the manufacturer to sign your boot sequence is entirely different, doesn't scale and is generally not welcome.
If the manufacturer allows you to put in the TPM your own set of keys then it's different as the user now has the power to do his own kernels and sign them with his own key and have it verify by the TPM.
If the user trusts Fedora to do that he'd store a Fedora public key in the TPM, if he doesn't he'll just not use TPM or re-sign kernels on update on his own with his personal key.
Simo.
On Mon, 27 Jun 2011 10:08:44 -0400 Simo Sorce simo@redhat.com wrote:
On Mon, 2011-06-27 at 15:12 +0200, Miloslav Trmač wrote:
On Mon, Jun 27, 2011 at 12:11 PM, Andrew Haley aph@redhat.com wrote:
On 24/06/11 20:49, Miloslav Trmač wrote:
On Fri, Jun 24, 2011 at 12:49 PM, Andrew Haley aph@redhat.com wrote:
What I don't understand is why this feature requires a binary blob. Surely whatever northbridge code is required can be free software, Is this just security through obscurity?
The purpose of the blob is to "measure" the system state; only the blob (and hardware reset) is allowed to restart the "measuring" process in the TPM. For this to work securely, the blob must be signed by someone that the TPM itself trusts - otherwise an attacker could replace the blob by something that lies about the system state.
<snip> > What we're saying, then, is that the TPM doesn't trust the owner > of the computer, but its manufacturer. It's impossible for a > user to decide who they trust.
First, the TPM (nor the CPU) really can't tell the difference between the owner of the computer and an author of a virus. It's all just software.
Second, every owner of a computer has to completely trust the manufacturer of the computer anyway - there are way too many ways the manufacturer can break the security of the system, e.g. backdoors in the CPU or motherboard, or hidden configurations of https://secure.wikimedia.org/wikipedia/en/wiki/Intel_AMT .
Placing trust in the manufacturer of the hardware puts the user in no worse position than they were before. And the user, of course, still has full control over whether to use the TPM or not, and what to use it for.
Trusting the manufacturer to not put bugs/backdoors is one thing. Having to depend on the manufacturer to sign your boot sequence is entirely different, doesn't scale and is generally not welcome.
If the manufacturer allows you to put in the TPM your own set of keys then it's different as the user now has the power to do his own kernels and sign them with his own key and have it verify by the TPM.
If the user trusts Fedora to do that he'd store a Fedora public key in the TPM, if he doesn't he'll just not use TPM or re-sign kernels on update on his own with his personal key.
On the subject of trust, may I repeat that this is at present entirely undocumented. The feature page contains nothing whatsoever saying what this is, except for a link to a sourceforge project.
The sourceforge project in turn contains nothing saying what the software does. Nothing.
I have found something that looks related here http://www.intel.com/technology/security/downloads/315168.htm
but is that it? How would anyone know?
On Mon, Jun 27, 2011 at 4:08 PM, Simo Sorce simo@redhat.com wrote:
On Mon, 2011-06-27 at 15:12 +0200, Miloslav Trmač wrote:
On Mon, Jun 27, 2011 at 12:11 PM, Andrew Haley aph@redhat.com wrote:
On 24/06/11 20:49, Miloslav Trmač wrote:
The purpose of the blob is to "measure" the system state; only the blob (and hardware reset) is allowed to restart the "measuring" process in the TPM. For this to work securely, the blob must be signed by someone that the TPM itself trusts - otherwise an attacker could replace the blob by something that lies about the system state.
<snip>
Trusting the manufacturer to not put bugs/backdoors is one thing. Having to depend on the manufacturer to sign your boot sequence is entirely different, doesn't scale and is generally not welcome.
The hardware manufacturer _only_ signs the sinit blob. Any kernel/OS you use can be measured/"protected" by the TPM without any further involvement of the manufacturer. Mirek
On Mon, 2011-06-27 at 16:53 +0200, Miloslav Trmač wrote:
On Mon, Jun 27, 2011 at 4:08 PM, Simo Sorce simo@redhat.com wrote:
On Mon, 2011-06-27 at 15:12 +0200, Miloslav Trmač wrote:
On Mon, Jun 27, 2011 at 12:11 PM, Andrew Haley aph@redhat.com wrote:
On 24/06/11 20:49, Miloslav Trmač wrote:
The purpose of the blob is to "measure" the system state; only the blob (and hardware reset) is allowed to restart the "measuring" process in the TPM. For this to work securely, the blob must be signed by someone that the TPM itself trusts - otherwise an attacker could replace the blob by something that lies about the system state.
<snip> > Trusting the manufacturer to not put bugs/backdoors is one thing. > Having to depend on the manufacturer to sign your boot sequence is > entirely different, doesn't scale and is generally not welcome.
The hardware manufacturer _only_ signs the sinit blob. Any kernel/OS you use can be measured/"protected" by the TPM without any further involvement of the manufacturer.
How does the sinit blob verify the kernel ? Can you add some documentation about that in the feature page request as others have asked please ?
Thanks, Simo.
On Mon, Jun 27, 2011 at 5:14 PM, Simo Sorce simo@redhat.com wrote:
On Mon, 2011-06-27 at 16:53 +0200, Miloslav Trmač wrote:
On Mon, Jun 27, 2011 at 4:08 PM, Simo Sorce simo@redhat.com wrote: The hardware manufacturer _only_ signs the sinit blob. Any kernel/OS you use can be measured/"protected" by the TPM without any further involvement of the manufacturer.
How does the sinit blob verify the kernel ?
It doesn't, really. My understanding is that it takes a hash of the contents of memory (and perhaps other state, I don't know) and submits this "measurement" to the TPM. The sinit blob doesn't contain any policy or configuration: it is only a mechanism for reducing the complete "system state" into a hash value.
The hardware owner configures the TPM so that submitting specific "measurements" is required to use keys stored in the TPM. What those keys do is not specified by the TPM: for example, they may be used to allow access to an encrypted hard drive, or to sign the "remote attestation" data.
Can you add some documentation about that in the feature page request as others have asked please ?
I'm afraid I'm not the feature owner, only a semi-informed outsider. I'd love to see the feature page updated/expanded as well. Mirek
2011/6/27 Miloslav Trmač mitr@volny.cz:
The hardware owner configures the TPM so that submitting specific "measurements" is required to use keys stored in the TPM.
To avoid a misunderstanding, "hardware owner" is "the customer", not "hardware manufacturer". Mirek
On 06/27/2011 11:27 AM, Miloslav Trmač wrote:
It doesn't, really. My understanding is that it takes a hash of the contents of memory (and perhaps other state, I don't know) and submits this "measurement" to the TPM. The sinit blob doesn't contain any policy or configuration: it is only a mechanism for reducing the complete "system state" into a hash value.
One of my biggest concerns here is that we don't know what the proprietary sinit blob is doing, nor do I think that it is likely that Intel will show us.
It seems to me that the situation is this:
Intel has convinced some hardware vendors (IBM and Dell, possibly others) to embed the sinit blob in their BIOSes on very new systems. Intel wants Fedora to automatically check for:
A) The system's capability to leverage found TPM hardware B) The presence of the sinit blob in the system BIOS
If A and B are true, then Fedora adds an additional grub configuration for a "trusted-kernel" scenario. As uncomfortable as I am with us enabling process around undocumented BIOS magic, there is some precedent within the Linux kernel for that sort of thing.
It also sounded like Intel wanted hooks in there so if A is true, but B is not, Fedora would prompt the user to download the sinit blob (arguably, B will be false on the majority of Fedora systems for at least the next few years). I am extremely opposed to this, for presumably obvious reasons.
~tom
== Fedora Project
Le Lun 27 juin 2011 15:12, Miloslav Trmač a écrit :
Placing trust in the manufacturer of the hardware puts the user in no worse position than they were before.
I don't call placing absolute vetting power in bios writer hands "no worse position". I don't thing anyone can point to a "good" bios on real world hardware.
On Tue, 2011-06-28 at 09:59 +0200, Nicolas Mailhot wrote:
Le Lun 27 juin 2011 15:12, Miloslav Trmač a écrit :
Placing trust in the manufacturer of the hardware puts the user in no worse position than they were before.
I don't call placing absolute vetting power in bios writer hands "no worse position". I don't thing anyone can point to a "good" bios on real world hardware.
I appreciate the disdain - no, really, trust me, I do - but you should realize that SMM means you already may have no control over the machine.
- ajax
On Tue, 2011-06-28 at 09:59 +0200, Nicolas Mailhot wrote:
Le Lun 27 juin 2011 15:12, Miloslav TrmaÄ a écrit :
Placing trust in the manufacturer of the hardware puts the user in no worse position than they were before.
I don't call placing absolute vetting power in bios writer hands "no worse position". I don't thing anyone can point to a "good" bios on real world hardware.
I appreciate the disdain - no, really, trust me, I do - but you should realize that SMM means you already may have no control over the machine.
Honestly what I think it comes down to in the end, for me, is information. We need to see more information in the Feature Request before this should even have a shot, as the flurry of questions shows. Additionally, if the information presented then clearly explains the situation, and all source code is available and it meets our guidlines, then we're probably better off with the technology available in Fedora than not. Vendors and RHEL customers will likely want it at some point, so we may as well have it in Fedora so that we can learn how to use it and how to counteract it if need be. Of course, if more information shows there to be signifigant conflict with our guidlines, then it's moot.
-J
- ajax
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 2011-06-28 at 10:01 -0400, Adam Jackson wrote:
On Tue, 2011-06-28 at 09:59 +0200, Nicolas Mailhot wrote:
Le Lun 27 juin 2011 15:12, Miloslav Trmač a écrit :
Placing trust in the manufacturer of the hardware puts the user in no worse position than they were before.
I don't call placing absolute vetting power in bios writer hands "no worse position". I don't thing anyone can point to a "good" bios on real world hardware.
I appreciate the disdain - no, really, trust me, I do - but you should realize that SMM means you already may have no control over the machine.
Well, the fact that BIOSes aren't open source means that anyway. As far as we the users are concerned, the BIOS is black box code which runs with the ultimate in administrative privileges. It could be doing _anything_ back there. SMM is a fairly standardized example of this, sure, but there's no way we can really be sure our BIOS isn't doing a zillion other 'bad things'. The point where you tip over into excessive paranoia is a bit hard to discern when you start going down this road, though...
Adam Williamson wrote:
On Tue, 2011-06-28 at 10:01 -0400, Adam Jackson wrote:
On Tue, 2011-06-28 at 09:59 +0200, Nicolas Mailhot wrote:
Le Lun 27 juin 2011 15:12, Miloslav Trmač a écrit :
Placing trust in the manufacturer of the hardware puts the user in no worse position than they were before.
I don't call placing absolute vetting power in bios writer hands "no worse position". I don't thing anyone can point to a "good" bios on real world hardware.
I appreciate the disdain - no, really, trust me, I do - but you should realize that SMM means you already may have no control over the machine.
Well, the fact that BIOSes aren't open source means that anyway.
That's not impossible to change though. I have never dared to try Coreboot myself, for fear of destroying my motherboard, but in principle it's possible to replace the BIOS in most current computers with a free implementation. It's looking like the TPM makes it impossible to replace Sinit with a free clone.
Björn Persson
On Wed, 2011-06-29 at 13:36 +0200, Björn Persson wrote:
Adam Williamson wrote:
On Tue, 2011-06-28 at 10:01 -0400, Adam Jackson wrote:
On Tue, 2011-06-28 at 09:59 +0200, Nicolas Mailhot wrote:
Le Lun 27 juin 2011 15:12, Miloslav Trmač a écrit :
Placing trust in the manufacturer of the hardware puts the user in no worse position than they were before.
I don't call placing absolute vetting power in bios writer hands "no worse position". I don't thing anyone can point to a "good" bios on real world hardware.
I appreciate the disdain - no, really, trust me, I do - but you should realize that SMM means you already may have no control over the machine.
Well, the fact that BIOSes aren't open source means that anyway.
That's not impossible to change though. I have never dared to try Coreboot myself, for fear of destroying my motherboard, but in principle it's possible to replace the BIOS in most current computers with a free implementation. It's looking like the TPM makes it impossible to replace Sinit with a free clone.
"Most current computers"? The support list - http://www.coreboot.org/Supported_Motherboards - is tiny, and doesn't include any even vaguely recent Intel chipset that I can see. And it includes a grand total of four laptops, two of which I've never heard of.
Adam Williamson wrote:
On Wed, 2011-06-29 at 13:36 +0200, Björn Persson wrote:
That's not impossible to change though. I have never dared to try Coreboot myself, for fear of destroying my motherboard, but in principle it's possible to replace the BIOS in most current computers with a free implementation. It's looking like the TPM makes it impossible to replace Sinit with a free clone.
"Most current computers"? The support list - http://www.coreboot.org/Supported_Motherboards - is tiny, and doesn't include any even vaguely recent Intel chipset that I can see. And it includes a grand total of four laptops, two of which I've never heard of.
Most current computers have their BIOS stored in a flash memory and allow you to overwrite it with a newer version. Instead of a newer version of the unfree BIOS you can install a free BIOS, if you have one. That is, *in principle* it's possible to replace the BIOS in any computer where the BIOS can be upgraded. Getting a free BIOS for your particular motherboard is a so-called simple matter of programming.
The point I'm trying to make is that there's a difference between an unfree Sinit and an unfree BIOS, in that while you can *theoretically* replace the BIOS, you will never be able to replace Sinit no matter how much you program, because the TPM will reject any Sinit clone that isn't signed by Intel. (At least that's what people seem to be saying around here.)
Björn Persson
On 06/29/2011 02:07 AM, Adam Williamson wrote:
On Tue, 2011-06-28 at 10:01 -0400, Adam Jackson wrote:
On Tue, 2011-06-28 at 09:59 +0200, Nicolas Mailhot wrote:
Le Lun 27 juin 2011 15:12, Miloslav Trmač a écrit :
Placing trust in the manufacturer of the hardware puts the user in no worse position than they were before.
I don't call placing absolute vetting power in bios writer hands "no worse position". I don't thing anyone can point to a "good" bios on real world hardware.
I appreciate the disdain - no, really, trust me, I do - but you should realize that SMM means you already may have no control over the machine.
Well, the fact that BIOSes aren't open source means that anyway. As far as we the users are concerned, the BIOS is black box code which runs with the ultimate in administrative privileges.
That's not as true as it used to be: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/
Most system vendors that ship this still have a bizarre belief that some drivers should remain proprietary, but other than that many are shipping fairly pristine checkouts.
Miloslav Trmač wrote:
First, the TPM (nor the CPU) really can't tell the difference between the owner of the computer and an author of a virus.
A jumper on the motherboard, or some other kind of physical circuit breaker, can do that. It would have been possible to design the TPM to accept a new master key only when a certain circuit is closed.
Björn Persson
On Wed, 2011-06-29 at 13:48 +0200, Björn Persson wrote:
Miloslav Trmač wrote:
First, the TPM (nor the CPU) really can't tell the difference between the owner of the computer and an author of a virus.
A jumper on the motherboard, or some other kind of physical circuit breaker, can do that. It would have been possible to design the TPM to accept a new master key only when a certain circuit is closed.
It would have been possible, but remember the purpose and history of Trusted Computing (of which this is a fundamental part) before it hit the commercial scene. Originally this was conceived as a way for government workers of various types to be able to use secure computing systems even *after* an unattended period. The whole concept is based on finding a way to circumvent the first law of information security: "If the attacker has physical access you don't have security." If a circumvention jumper were designed into the system this would defeat the purpose.
Today we are having this discussion in the commercial and private space only because it is a technology the government already understands and would therefore feel confident in designing anti-circumvention legislation around to suit the needs of the pro-DRM folks. It has the added benefit that a red herring "security for everyone" argument can be made to support the concept of including DRM enablers into all digital devices in the commercial space. Of course, the TPM piece being an Intel-only standard and the software behind it being a black-box set of processes undercuts the non-DRM commercial hype at the root. This being naturally of benefit to Intel far more than it is of benefit to anyone interested in actually knowing what their system is up to (one phrase for that is "information security") is easy to overlook.
The idea that government interest is still driving this is a bit shallow -- there are already functionally identical systems which have been fielded (and the customer in this case, who really is concerned with complete security, does not have the handicap of being made to trust any black-box processes at any level, anywhere) and I've already attempted to place this discussion in perspective elsewhere. In short, this is a step toward DRM of a sort nobody can quite fathom yet. Ultimately it will prove to be scary to the point that I seriously feel it will be dropped in the commercial space and media providers (and Microsoft) will simply have to evolve or get eaten by whoever else does first.
-Iwao
On Thu, 2011-06-23 at 18:15 +0200, Miloslav Trmač wrote:
On Thu, Jun 23, 2011 at 4:21 PM, JB jb.1234abcd@gmail.com wrote:
I have done some inventory on this topic, and have some questions.
I'm not really an expert on this... Hopefully someone will correct my mistakes.
Why do you need Trusted Boot mechanism to ensure that identified and origin- verified Linux kernel is booted ? Why signing a kernel (a la GPG) is not good enough to verify its origin at boot time ?
The TPM allows verifying that this kernel (and only this kernel) is actually running. An attacker with access to the hard drive ("evil maid") can modify the code to disable any signature check that would be done in software (e.t. inside grub); TPM cannot be bypassed this way.
How is this possible? The kernel was somehow installed. TPM was informed about it (I don't know, sha hash was written into a flash which is physically in the processor?).
Why attacker with physical access to the computer can't install his tampered kernel and save its hash?
2011/7/18 Denys Vlasenko dvlasenk@redhat.com:
On Thu, 2011-06-23 at 18:15 +0200, Miloslav Trmač wrote:
The TPM allows verifying that this kernel (and only this kernel) is actually running. An attacker with access to the hard drive ("evil maid") can modify the code to disable any signature check that would be done in software (e.t. inside grub); TPM cannot be bypassed this way.
How is this possible? The kernel was somehow installed. TPM was informed about it (I don't know, sha hash was written into a flash which is physically in the processor?).
I'm not quite sure how the installation procedure is supposed to work - however, in the end, a hash that represents the "right" system is stored in the TPM. Cryptographic keys that are stored in the TPM are then bound to this hash, and accessible only when the booting system matches this hash.
Why attacker with physical access to the computer can't install his tampered kernel and save its hash?
Once the cryptographic keys are bound to a specific hash, the attacker can not access them without booting system that matches this hash. An attacker can not boot a different system and then change the hash to which the key is bound. Mirek
On 06/23/2011 10:21 AM, JB wrote:
The Intel Trusted Platform consists of two components:
- Trusted Platform Module (TPM) chip A hardware component, consisting of cryptographic processor and secure memory.
- Trusted Boot A software component, open-source and partially close-source (?) components, in Fedora packages.
Why does the TB require closed-source components? I understand that the code has to be inalterable, but since it is a small and well-defined piece of infrastructure it could be crypto-signed once and for all. Having source code access doesn't give anyone more privileges than a binary blob.
Two questions:
1. Can you please add some information to the feature page? I can't tell what TrustedBoot is and how it works.
2. This seems like Trusted Computing, which got shot down in flames. Does TrustedBoot go against the core values of Fedora?
nd
On 22/06/11 21:02, Matthew Garrett wrote:
http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed feature for F16. We've traditionally had a hard objection to the functionality because it required either the distribution or downloading of binary code that ran on the host CPU, but it seems that there'll shortly be systems that incorporate the appropriate sinit blob in their BIOS, which is a boundary we've traditionally been fine with.
However, this is the kind of feature that has a pretty significant impact on the distribution as a whole. Fesco decided that we should probably have a broader discussion about the topic. The most obvious issues are finding a sensible way to incorporate this into Anaconda, but it's also then necessary to make sure that bootloader configuration is updated appropriately.
Outside that, is there any other impact? Does tboot perform any verification of the kernels, and if so how is that configured? Is the expectation that an install configured with TXT will only boot trusted kernels, and if so what mechanism is used to verify the kernel? Is there any further integration work that has to be performed for this to be useful?
On Fri, 2011-06-24 at 22:21 +0200, nodata wrote:
- This seems like Trusted Computing, which got shot down in flames.
Who shot it and why ?
Does TrustedBoot go against the core values of Fedora?
Only if it is not under user control, otherwise it is a very useful feature.
Simo.
On Fri, 24 Jun 2011 17:09:22 -0400 Simo Sorce simo@redhat.com wrote:
On Fri, 2011-06-24 at 22:21 +0200, nodata wrote:
- This seems like Trusted Computing, which got shot down in flames.
Who shot it and why ?
Does TrustedBoot go against the core values of Fedora?
Only if it is not under user control, otherwise it is a very useful feature.
Nevertheless, the feature page contains no documentation about what it actually is. Neither does the sourceforge.net page of the project.
It seems like a reasonable request that this documentation be added.
Simo.
On Fri, 2011-06-24 at 17:15 -0400, Bernd Stramm wrote:
On Fri, 24 Jun 2011 17:09:22 -0400 Simo Sorce simo@redhat.com wrote:
On Fri, 2011-06-24 at 22:21 +0200, nodata wrote:
- This seems like Trusted Computing, which got shot down in flames.
Who shot it and why ?
Does TrustedBoot go against the core values of Fedora?
Only if it is not under user control, otherwise it is a very useful feature.
Nevertheless, the feature page contains no documentation about what it actually is. Neither does the sourceforge.net page of the project.
It seems like a reasonable request that this documentation be added.
I agree on this point.
Simo.
Hi,
On Fri, Jun 24, 2011 at 5:09 PM, Simo Sorce simo@redhat.com wrote:
On Fri, 2011-06-24 at 22:21 +0200, nodata wrote:
- This seems like Trusted Computing, which got shot down in flames.
Who shot it and why ?
I don't know about Trusted Computing but this does remind me of the Pentium III processor serial number that wasn't well received - even though in theory it had what many people would consider a reasonable purpose. In other words, tracking down CPUs that were sometimes stolen by the truckload.
Does TrustedBoot go against the core values of Fedora?
Only if it is not under user control, otherwise it is a very useful feature.
In a sense, part of it isn't under user control. There is a secret in there, held against the user, and possibly known by the manufacturer or other third parties. There is also a black box of code that could do anything. I'm not really that paranoid but it is worth considering the worst case, just as a theoretical possibility. What if the device became standard by virtue of being bundled with every consumer device... what if it became crucial to system operation somehow... what if that device could then be disabled remotely, either rendered useless by the secret being disclosed, or some unknown functionality could be triggered in that signed but opaque blob of code.
Already there are systems that have whitelisted hardware (eg. wireless cards in netbooks) and the BIOS polices the presence of the right device. If you make unauthorised modifications to the BIOS, you can install any compatible wireless card (or WWAN device). BUT if the BIOS was signed and loaded by a trusted method, this option would not be available.
Apart from that there is the aspect of identification - this is as good a way of identifying a system as the processor serial number was.
I think it is worth including in open source systems, but only so the devices and methods can be better understood, and probably turned off / disabled at the earliest opportunity if there isn't a compelling benefit to having them.
-Cam
Once upon a time, Camilo Mesias camilo@mesias.co.uk said:
In a sense, part of it isn't under user control. There is a secret in there, held against the user, and possibly known by the manufacturer or other third parties. There is also a black box of code that could do anything.
You already have that; it is called System Management Mode.
I'm not really that paranoid but it is worth considering the worst case, just as a theoretical possibility. What if the device became standard by virtue of being bundled with every consumer device... what if it became crucial to system operation somehow...
Fedora supporting or not supporting it will have zero impact on that outcome happening or not happening.
Already there are systems that have whitelisted hardware (eg. wireless cards in netbooks) and the BIOS polices the presence of the right device. If you make unauthorised modifications to the BIOS, you can install any compatible wireless card (or WWAN device). BUT if the BIOS was signed and loaded by a trusted method, this option would not be available.
All of that is pre-kernel, so either can or cannot happen no matter what Fedora does. None of that has any bearing on the technical discussion about whether Fedora should or should not include this functionality in the installer.
I think there is some misunderstanding about what the discussion is supposed to be about. The supporting open source code is already in Fedora. The feature request is simply to modify grubby/anaconda to set up the boot entries to include the support by default (or when the hardware is found).
On 25/06/11 18:52, Chris Adams wrote:
Once upon a time, Camilo Mesiascamilo@mesias.co.uk said:
In a sense, part of it isn't under user control. There is a secret in there, held against the user, and possibly known by the manufacturer or other third parties. There is also a black box of code that could do anything.
You already have that; it is called System Management Mode.
I'm not really that paranoid but it is worth considering the worst case, just as a theoretical possibility. What if the device became standard by virtue of being bundled with every consumer device... what if it became crucial to system operation somehow...
Fedora supporting or not supporting it will have zero impact on that outcome happening or not happening.
Already there are systems that have whitelisted hardware (eg. wireless cards in netbooks) and the BIOS polices the presence of the right device. If you make unauthorised modifications to the BIOS, you can install any compatible wireless card (or WWAN device). BUT if the BIOS was signed and loaded by a trusted method, this option would not be available.
All of that is pre-kernel, so either can or cannot happen no matter what Fedora does. None of that has any bearing on the technical discussion about whether Fedora should or should not include this functionality in the installer.
I think there is some misunderstanding about what the discussion is supposed to be about. The supporting open source code is already in Fedora. The feature request is simply to modify grubby/anaconda to set up the boot entries to include the support by default (or when the hardware is found).
Please could you update the Feature page to say what exactly Trusted Boot is?
Chris Adams <cmadams <at> hiwaay.net> writes:
... I think there is some misunderstanding about what the discussion is supposed to be about. The supporting open source code is already in Fedora. The feature request is simply to modify grubby/anaconda to set up the boot entries to include the support by default (or when the hardware is found).
Hi,
I think Fedora should be careful here - it is a minefield. It is treacherous, as already expressed by other and competent people. Respect them, there was a reason they said that. I personally think that free and open-source product should stay away from TPM entirely.
One one hand - it is about trusted boot:
This can already be achieved partially now, with open-source tools (GPG, etc), and can be enhanced with e.g. a combination of hardware/software solution that would be *non-hardwired*, *portable*, *open-source* and *"free"*, and up to machine owner and user to utilize. Signed where appropriate with *your* GPG key. Think of what the trend and the state-of-art-and-mind are in regard to this; Iwao's post is very helpful here. http://lists.fedoraproject.org/pipermail/devel/2011-June/153456.html This could be achieved now or soon without deep fundamental considerations, by the open-source community itself.
On the other hand - it is about OS isolation (OS rings):
Ring (computer security) http://en.wikipedia.org/wiki/Ring_%28computer_security%29
This is a separate issue, in my mind. In this sense, TPM is about "ring -1", and in the future "ring -2", etc :-) This is about virtualization, and more. It goes much deeper into OS design and architecture, hardware and software. It should be addressed fundamentally by competent people, companies and organizations. Leave it to them, but watch and participate.
Finally. Btw, TPM, or TXT exactly, can be hacked too (that has been done already).
JB
JB <jb.1234abcd <at> gmail.com> writes:
... Btw, TPM, or TXT exactly, can be hacked too (that has been done already). ...
... and she is cute too :-)
http://theinvisiblethings.blogspot.com/search/label/trusted%20execution%20te...
and some more ...
http://siblog.mcafee.com/data-protection/tpm-undressed http://www.nzherald.co.nz/technology/news/article.cfm?c_id=5&objectid=10...
... and those we do not know about ^.^
JB
On Tue, Jun 28, 2011 at 08:21:23PM +0000, JB wrote:
JB <jb.1234abcd <at> gmail.com> writes:
... Btw, TPM, or TXT exactly, can be hacked too (that has been done already). ...
... and she is cute too :-)
Which is irrelevant to the discussion and also inappropriate for this list.
On 06/25/2011 04:13 AM, Camilo Mesias wrote:
On Fri, Jun 24, 2011 at 5:09 PM, Simo Sorcesimo@redhat.com wrote:
On Fri, 2011-06-24 at 22:21 +0200, nodata wrote:
- This seems like Trusted Computing, which got shot down in flames.
Who shot it and why ?
I don't know about Trusted Computing but this does remind me of the Pentium III processor serial number that wasn't well received - even though in theory it had what many people would consider a reasonable purpose. In other words, tracking down CPUs that were sometimes stolen by the truckload.
the processor serial number (PSN) wasn't shut down---every post-PIII CPU has it. The access is often disabled by the BIOS, but it's there:
http://pcworld.about.net/magazine/1903p198id38601.htm
I think that TPC requires that PSN are enabled, but I can't think of why.
On 06/28/2011 03:25 PM, Przemek Klosowski wrote:
On 06/25/2011 04:13 AM, Camilo Mesias wrote:
On Fri, Jun 24, 2011 at 5:09 PM, Simo Sorcesimo@redhat.com wrote:
On Fri, 2011-06-24 at 22:21 +0200, nodata wrote:
- This seems like Trusted Computing, which got shot down in flames.
Who shot it and why ?
I don't know about Trusted Computing but this does remind me of the Pentium III processor serial number that wasn't well received - even though in theory it had what many people would consider a reasonable purpose. In other words, tracking down CPUs that were sometimes stolen by the truckload.
the processor serial number (PSN) wasn't shut down---every post-PIII CPU has it. The access is often disabled by the BIOS, but it's there:
http://pcworld.about.net/magazine/1903p198id38601.htm
I think that TPC requires that PSN are enabled, but I can't think of why.
My guess is that it checks for that changing as part of its 'hash' if it changes we know something moved... maybe we're no longer on original hardware etc...
On Tue, 28 Jun 2011, Przemek Klosowski wrote:
the processor serial number (PSN) wasn't shut down---every post-PIII CPU has it. The access is often disabled by the BIOS, but it's there:
http://pcworld.about.net/magazine/1903p198id38601.htm
I think that TPC requires that PSN are enabled, but I can't think of why.
probably to provide a unique serial number to use as part of the TPM attestation private key generation, to ensure uniqueness and to prevent a replay type attack
-- Russ herrold
-
Adam Jackson -
Adam Williamson -
Alexander Boström -
Andrew Haley -
bernd.stramm＠gmail.com -
Björn Persson -
Camilo Mesias -
Chris Adams -
Clyde E. Kunkel -
Daniel J Walsh -
Denys Vlasenko -
Eric Paris -
Genes MailLists -
Gregory Maxwell -
inode0 -
James Morris -
JB -
Jon Ciesla -
Kevin Fenzi -
Matthew Garrett -
Michael Cronenworth -
Michael Ekstrand -
Miloslav Trmač -
Nathanael D. Noblet -
Nicolas Mailhot -
nodata -
Peter Jones -
Peter Robinson -
Przemek Klosowski -
R P Herrold -
Rahul Sundaram -
Seth Vidal -
Simo Sorce -
Till Maas -
Tom Callaway -
Tomas Mraz -
Wei, Gang -
夜神 岩男