[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TPM support status ?

From: Duboucher Thomas
Subject: Re: TPM support status ?
Date: Wed, 19 Aug 2009 19:25:11 +0200
User-agent: Thunderbird (Windows/20090605)

Hash: SHA1

Isaac Dupree a écrit :
> Suppose you are the proud technical support person at a third-world
> school that just bought a thousand OLPC XOs.  You, as part of your
> country's government, are instructed to own those XOs.  If they are
> stolen and get into the hands of innocent third-world civilians who want
> a computer, those computers are instructed to shut off within 24 hours
> and demand to be returned to their original location before they're
> willing to work again.  This harms ordinary users who loved their
> student computer; they might choose not to return it anyway.  It does
> not harm the thieves who steal the XOs and break them down into parts
> and sell the parts.  Civilians with enough expertise might be able to
> replace the BIOS flash to get a working computer again, but there will
> be many ordinary users who can't figure out how to do this (or perhaps,
> don't have the tools). This restriction is not necessarily what makes
> OLPC designers happy, it is merely a condition set by many governments
> who decided to shell out lots of money for the XOs for schools.
I don't see the link with TPM. oO

> Technical measures can never decide who, morally, "owns" a computer.
> When software technical measures do try to decide that, it is almost
> always the technically adept and/or the manufacturers who win.  In a
> project for a Free world, I suspect we want to give our best chance to
> anyone who ends up with a computer by any means... It's why I still have
> set an unrestricted boot option on my computer (without access to my
> personal-data encryption password of course - it's in my head) so that
> if someone accidentally ends up with my computer and doesn't return it
> and doesn't figure out how to reinstall an OS on it, the computer won't
> economically go completely to waste... :-)
I completly agree with this. However, in my world, I have a lot people
that loves jokes, so I ended up with some protections ;)

> The cost of taking that stance is that when you remote-access a
> computer, it (more easily)* might be running different software than you
> expected.  Is that so unreasonable?  If you need an Internet-connected
> secured computer, maybe you can put it in your home, or rent one from a
> local company (or friend) who you trust to keep your data safe because
> you know them?
Hey, that's the point. Can you trust your computer? Can you trust the
software on your computer? Can you trust the hardware on your computer?
Can you trust the local company whom you rented a computer from (or
perhpas your closest cyber-café ... where in France they have to log
everything for anti-terrorism counter-measure ...)?

> *some options:
> - Lock down not very much at all: Let anyone boot a CD, or even log in
> directly as root, or at least replace your hard drive.  Allowing only
> the former probably makes you safer from someone lazy grabbing your
> computer out of your hands and deleting your files in a stroke of anger;
> adding some time/practicality delay that's still much less than the
> nuisance of replacing hardware can be an okay compromise.
I can imagine a world with computers you can access from free and from
whom you can boot with your USB pen-drive (or trust the installed OS, or
whatever you want). But this world is still far away from here ... :|

> - Lock down via open chain of trust: Coreboot, and so forth, verifying
> signatures.  Booting a CD, and removing/modifying/replacing your hard
> drive, neither will allow the computer to boot something different.
> Different software can happen if "attacker" figured out how to
> physically replace your BIOS.  This is claiming ownership of your
> computer for as long as it remains your computer (or until someone
> steals your personal passwords or personal crypto-keys).  It's open
> design, but it's worth noticing that by choosing even this, you are
> still trying to using technical measures to decide who owns a
> computer... it just gets less 1984-esque when someone does decide to
> replace your computer's BIOS (they can use a standard chip rather than a
> horrible hack discovered by black hats)... This choice might be a good
> one to use in airplane cockpits.
No! No! No! and No! Coreboot is not an CRTM, and then you can't speak
about chain of trust if you are starting it with Coreboot ... It is
already very difficult to consider the TPM as a CRTM since there are
design flaws.
Also, you are not owning a computer by using a chain of trust. You are
only sure that the software you trust on your computer haven't been
tampered. And you can keep trusting them, even if they have a backdoor
you weren't aware of! ;)

> - Lock down via proprietary crypto chip (TPM).  Different software can
> happen if "attacker" figured out how to break into your TPM, which is
> actually quite possibly easier, not harder, than replacing hardware
> because the TPMs are closed systems that don't disclose their design and
> flaws...
Wow! Software hacked TPM? Software breaking into TPM? I must be missing
something. :|
Every technology has its design and its implementation, and also its
design flaws and implementation flaws. Remember Debian and OpenSSL.
Well, if a chip has a design flaw, it is more expensive to change it;
however, people that will truly require it will also be able to. ;)

> This option is not safe from TPM manufacturers even if it does
> *seem* convenient and secure (considering how many PCs have TPMs these
> days).  This might be okay for airplanes because -Airplane manufacturers
> are big enough to negotiate with TPM manufacturers -Airplane control
> systems had better never function as ordinary computers for ordinary
> people! (-Isolating the risks in a smaller chip might be safer from
> electromagnetic effects; Except that you don't actually get reliability
> that way.  You can make every security measure here, and even TPM remote
> attestation, flawed, as soon as your RAM becomes unpredictable.  Not in
> a convenient way, but it should definitely be possible..)  Also, none of
> the airplane arguments really apply to small, non-life-critical systems.
Airplane manufacter aren't using ordinary computer ...
>  If car manufacturers build PCs into the cars for people's enjoyment,
> the PCs should not be locked down; the critical circuits should use
> separate chips anyway, because it's just better engineering practice not
> to rely on a fast multi-purpose computer when you don't have to.
... nor does car manufacturer.

> I think, we need to be activists for open (e.g. Coreboot-based)
> security.  Fewer of its possible scenarios lead to dystopian
> circumstances.  Too many people expect and demand a logical chain of
> security for their computers (I'm not one of them, I don't want to lock
> down my laptop, as above).  I don't know if this chain of security is
> "useful" in an absolute sense, but it is nevertheless part of the
> struggle to make computers more open and understandable, including
> making people understand better the comparative role of TPM.  I believe
> this role is: a very badly implemented form of basically the Coreboot
> chain of things, plus a form of remote attestation that requires you (or
> anyone) to tech-battle the manufacturer to circumvent (or instead of
> battling, maybe you're an agency that can convince manufacturers to give
> you a backdoor. Money and slimy promises are good tools for this.).  I'm
> not sure, I might be missing something here -- what are you thinking
> about it?
This chain of trust is useful for people that have to work with a
computer and data in an untrusted environnement, and that's how and what
it was designed for. Basically, the computer says "trust me", but now
you know you can trust it (well, "trust" is very difficult, does anyone
truly trust the microcode in your ethernet daughter-board?)

> -Isaac
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]