UEFI Palladium reborn Nightmare.

[LoadWB]

I just attended the NSA Trusted Computing conference last week.  I won't go into the details of the TPC panel discussion and what-not. Suffice to say that, yes, the manufacturer can, if it wanted to, lock out an OS other than Windows (or whatever comes installed.)

If the manufacturer will not provide you with what's necessary to undo that and install another OS, then you buy from someone else.  Period.

The benefits of the Trusted Platform far outweigh the negatives in the DRM-scare camp.  To me, this is like people who buy Apple products and then bitch because they can't install anything they want.  No shyt, Sherlock.

We will see more of this UEFI/TPC stuff coming down the pipe, and it needs to.  It is virtually impossible to secure a system with software alone.  There must be cohesion between the hardware and software.  After all, trusted software is only as trust-worthy as the hardware on which it runs.

I saw and heard about stuff last week which is just out-right scary, and makes me eager to attend DefCon or a Black Hat.

[LoadWB]

Yeah, that works as long as you assume that there's enough demand for alternative-OS booting that manufacturers don't think it's worthwhile to let themselves be bought off. After all, it's not like Microsoft has been known to strong-arm PC vendors out of providing alternative OSes before, or anything...

History shows that, at this point, there has been no major push by manufacturers to eliminate "alternate" operating systems.  And given AMD's recent push into open source drivers for Linux, I doubt there ever will be.

Could you please explain to me what real benefits this would offer?

This is just a basic example, and just the tip of the iceberg.  Prevention of unauthorized changes to the processes in the system responsible for initial boot prior to hand-off to the operating system, for one.  And in the event an unauthorized change occurs, stopping the boot process cold to prevent further compromise.

Two of the infection vectors used by Stuxnet would have been stopped by an operational trusted-platform system, as could the TDSS root-kit.

Because if it just down to preventing booting of unauthorized operating systems for security purposes...you can do that with existing computers. Every half-decent BIOS in every motherboard manufactured in the past five years has had the ability to disable booting from external media, and to secure the BIOS itself via password. It's not going to be any more help against theft, either; if your security model is such that theft is a realistic possibility, it's not the computer that's the problem.

:rolleyes:I hope you're just trolling, because it seems like you're stuck on the alternate-boot idea, forgetting for a second that a BIOS password can be defeated.  The first maxim of security is, simply put, if they own our box they own your data.  If physical security is a problem, your issues are elsewhere.

[LoadWB]

Again, though, this is entirely possible to accomplish without mechanisms that could be co-opted to enforce software lock-in.

Interesting.  So, what you're telling me is that a firmware based root-kit is absolutely possible to detect in software which has to implicitly trust the hardware which has been infected.  The TPM can work directly with the CPU to look at code to be executed and halt the CPU if the code doesn't pass muster, with no software interaction what-so-ever.  This virtually eliminates the capability of the hardware to lie to the operating system, as the TPM store is hardened against being manipulated without the proper key.

I'm beginning to build TC-based systems and I expect to use a private key which I generate for each customer.

And how many of them couldn't have been stopped with a less problematic method of boot security?

This does not rebuke in any way the efficacy of the platform.  Although, in a well-locked down system it is possible that it simply would never have worked.  I don't have enough information on it to speak at that level of certainty.  Even so, I would not argue that I shouldn't bother to put a dead-bolt on my door because the window can be kicked in.

That's entirely my point - boot security isn't a question of whether you're using signed or unsigned software from an external source, it's whether you're letting there be an option of using software from an external source. If security is a concern and yet you're leaving the possibility of booting the system from a removable drive, you're doing it wrong.

I would say it's a matter of both.  If the signature in the BIOS, option ROMs, boot block, etc. does not match what the TPM knows they should be, then it all stops.  And in this scenario you could still use external boot devices under the purview of the platform, so long as the external source has been identified to the TPM.

Simply preventing booting from external devices is not sufficient.

You do have a fair point about BIOS passwords not being flawless - so make it a jumper setting on the board or something. It's not that hard to come up with solutions other than "put the entire system under the control of a licensing authority that you don't know can't be bought off or themselves cracked" (say, for example, DigiNotar's recent breach.)

A general compromise like that is always a problem.  Look at the code signing certificates for Microsoft which were used to sign trojan drivers, or the sound card manufacturer whose signing keys were pilfered.  Keeping your private keys private is absolutely a concern -- vendors are being encouraged to protect them as though lives depend upon their safety -- but not any reason to junk the entire idea.  And it can be done; AFAIK, no one has yet cracked the encryption used to apply micro-code patches to Intel processors.

I asked the engineers present at the conference from AMD and Intel about the BIOS jumpers.  It's a good idea, I think, but still not the magic bullet.

To summarize: password-protecting the BIOS, setting the BIOS jumper to "write protect," and disabling external boot devices is not enough anymore.

[LoadWB]

...

The long and short of it is, no operating system nor hardware can meet perfect security, because perfect security is impossible.

[LoadWB]

Absolutely correct, all you can ever do is approach it. But there's multiple ways to do that, and some of them don't involve going off on bunny trail like OS signage when the root causes could be addressed instead.

I still assert that you're absolutely incorrect.  Hardware and software cannot be left perpetually immutable, and the changes necessarily inherent must be able to be validated in order to be trusted.  Allowing authorized changes also necessarily invites unauthorized modifications.

This is, as you say, fundamentally insecure, but it is not flawed -- again, it is necessary.

I believe that the TPC addresses this well, in which you can have completely separate entities, in hardware and software, readily identify each other for the purpose of trust.

There is no "sane" OS in which you can perfectly achieve separation between user and system which cannot be breached.  I remember when BSD jails were the end-all be-all, and then they were broken.  Hell, I watched a demonstration in which a VM was able to steal information from another VM by compromising their shared hyper-visor.  There are plenty of white papers out there, information from N.I.S.T., I.E.E.E., and so on which speak very openly on this.  I just spent a week listening to and watching how exactly what you propose is simply not viable from experts who actually build the components, not simple academics with theories.  I spent my own hard-earned money on my learning experience and as much as it may sound like a dodge, I challenge you to do some real research on the matter.  (I'll have access to the presentations once I complete my 29 page survey :madashell: and will make some of them available, if you're interested.)

None of this withstanding, on the whole, anti-TPM arguments reek of the disciples of Stallman, who has a rampant distrust for the Evil Corporations.  The reaction to the Trusted Platform is wholly over-blown, just as much as every new security measure which has been decried as Yet Another DRM.  (DRM is real, but it's not everywhere like the bogeyman.)  Palladium never came to be the disaster the prophets said it would be.  No motherboard manufacturer which wants to keep a presence in a free market will bow to only including Microsoft keys in their TPMs -- aside from the TPG expressly forbiding such a practice.  That doesn't stop OEMs from doing it, but the TPG is working closely with the industry to ensure that things remain open.

I refuse to subscribe to the tin-foil hat brigade on this one.