Re: [IP] Open Source TCPA driver and white papers (fwd)
On Tue, 11 Feb 2003, Michel Messerschmidt wrote:
> The TPM is a mandatory part of the TCPA specifications.
> There will be no TCPA without TPM.
That makes sense, TPM is just key storage.
> And there will be no TCPA-enabled system with complete user control.
> Just look at the main specification:
> - users can't access nor alter the Endorsement Key
> - the TPM can't be disabled completely. This allows operating systems
>that bind ("product activation" ?) themselves to an unique TPM and
>refuse to start if it's not fully activated.
>
> If a system doesn't meet these reqirements (as the IBM paper suggests)
> it isn't a TCPA system.
Not having access to the secret key inside the TPM is what makes the
hardware secure. Not being able to disable it is a problem for sure.
To me that implies the user does not have control. So my idea of a
"good" TCPA is not part of the spec. Too bad. That makes it
impossible to sell to anyone with a brain cell left.
> TCPA uses some interesting possibilities that may enhance system
> security. But with the current specifications, it likely destroys any
> privacy that's left on todays systems.
If they want to sell it, they'll have to fix the specs. Any IT pro
is going to explain to the CEO how it allows somebody else access
to all a companies data, and poof, TCPA goes away.
Patience, persistence, truth,
Dr. mike
Re: [IP] Open Source TCPA driver and white papers (fwd)
On Sun, Feb 09, 2003 at 02:32:13PM -0800, Mike Rosing wrote:
> TPM != TCPA. TCPA with *user* control is good.
The TPM is a mandatory part of the TCPA specifications.
There will be no TCPA without TPM.
And there will be no TCPA-enabled system with complete user control.
Just look at the main specification:
- users can't access nor alter the Endorsement Key
- the TPM can't be disabled completely. This allows operating systems
that bind ("product activation" ?) themselves to an unique TPM and
refuse to start if it's not fully activated.
If a system doesn't meet these reqirements (as the IBM paper suggests)
it isn't a TCPA system.
> > Therefore for DRM purposes TCPA and Palladium are both socially bad
> > technologies.
>
> It's bad only if the *user* does not have control over their own machines.
> If each enterprise can control their own machines, completely
> independently of all other external organizations, then TCPA could be
> really useful. If only Bill Gates controls all machines, it's bad for the
> rest of us (but pretty damn good for Bill!!)
TCPA uses some interesting possibilities that may enhance system
security. But with the current specifications, it likely destroys any
privacy that's left on todays systems.
--
Michel Messerschmidt [EMAIL PROTECTED]
antiVirusTestCenter, Computer Science, University of Hamburg
Re: [IP] Open Source TCPA driver and white papers (fwd)
On Sun, 9 Feb 2003, Anonymous via the Cypherpunks Tonga Remailer wrote: > However note: you can't defend TCPA as being "good" vs Palladium "bad" > (as you did by in an earlier post) by saying that TCPA only provides > key storage. TPM != TCPA. TCPA with *user* control is good. > As Michel noted TCPA and Palladium both provide remote attestation and > sealing, and it is this pair of functions which provides the DRM > functionality. > > Therefore for DRM purposes TCPA and Palladium are both socially bad > technologies. It's bad only if the *user* does not have control over their own machines. If each enterprise can control their own machines, completely independently of all other external organizations, then TCPA could be really useful. If only Bill Gates controls all machines, it's bad for the rest of us (but pretty damn good for Bill!!) Patience, persistence, truth, Dr. mike
Re: [IP] Open Source TCPA driver and white papers (fwd)
Mike Rosing wrote: > > BTW, why should I need a TPM only for secure key storage ? > > Any smartcard is better suited for this. > > Because it's soldered into the portable. For an enterprise that means > they *know* each portable out in the field is held by the correct > user. With a smart card, they only know the card is held by the > correct user. A key store chip could be useful for some applications. However note: you can't defend TCPA as being "good" vs Palladium "bad" (as you did by in an earlier post) by saying that TCPA only provides key storage. As Michel noted TCPA and Palladium both provide remote attestation and sealing, and it is this pair of functions which provides the DRM functionality. Therefore for DRM purposes TCPA and Palladium are both socially bad technologies.
Re: [IP] Open Source TCPA driver and white papers (fwd)
On Sat, 8 Feb 2003, Michel Messerschmidt wrote: > AFAIK, IBM's "embedded security subsystem 1.0" is only a key > storage device (Atmel AT90SP0801 chip). > But the TPM we're talking about is part of the TCPA compliant > "embedded security subsystem 2.0" which supports all specified > TPM functions, even if the released TPM driver can't use all > of them (for now). > > BTW, why should I need a TPM only for secure key storage ? > Any smartcard is better suited for this. Because it's soldered into the portable. For an enterprise that means they *know* each portable out in the field is held by the correct user. With a smart card, they only know the card is held by the correct user. It ain't perfect, but it's useful for the real world. Patience, persistence, truth, Dr. mike
Re: [IP] Open Source TCPA driver and white papers (fwd)
On Wed, Feb 05, 2003 at 07:15:50AM -0800, Mike Rosing wrote: > On Tue, 4 Feb 2003, AARG! Anonymous wrote: > > > The main features of TCPA are: > > > > - key storage > > The IBM TPM does this part. AFAIK, IBM's "embedded security subsystem 1.0" is only a key storage device (Atmel AT90SP0801 chip). But the TPM we're talking about is part of the TCPA compliant "embedded security subsystem 2.0" which supports all specified TPM functions, even if the released TPM driver can't use all of them (for now). BTW, why should I need a TPM only for secure key storage ? Any smartcard is better suited for this. -- Michel Messerschmidt [EMAIL PROTECTED] http://www.michel-messerschmidt.de
Re: [IP] Open Source TCPA driver and white papers (fwd)
On Thu, 6 Feb 2003, Anonymous via the Cypherpunks Tonga Remailer wrote: > I think you may have been mislead by the slant of paper. > > Quoting from the paper: > > http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf > > you will see: > > | The TCPA chip is not particularly suited to DRM. While it does have > | the ability to report signed PCR information, and this information > | could be used to prevent playback unless a trusted operating system > | and application were in use, this type of scheme would be a > | nightmare for content providers to manage. Any change to the BIOS, > | the operating system, or the application would change the reported > | values. How could content providers recognize which reported PCR > | values were good, given the myriad platforms, operating system > | versions, and frequent software patches? > > which clearly admits that the IBM TPM does implement the full set of > TCPA functionality as specified in the openly published TCPA spec, and > for the purposes of our discussion specifically as you see it does > implement the remote attestation feature. They can say all they want in a white paper. I was looking at the source code. That can only query the tpm chip. The chip itself contains no rom, you can't jump into it. In order to meet the requirement of tcpa it needs a secure execution region, and the IBM TPM simply doesn't have it. > (Though the author makes some unimaginative claims that it is "not > suited for DRM" because of upgrades may make that difficult to manage. > Any sane software architecture built on top of this tech can easily > tackle that "problem".) And any hacker can bypass it, which is what the guys at IBM are saying. > I'd think the more likely reason they want to downplay that TCPA is a > DRM enabling technology is because it's bad publicity for a hardware > manufacturer. I doubt it. If they could do what RIAA wants they could make a lot of money. Morals come second to money. Patience, persistence, truth, Dr. mike
Re: [IP] Open Source TCPA driver and white papers (fwd)
Mike Rosing wrote: > > - secure boot > > - sealing > > - remote attestation > > It does *not* do these parts. I think you may have been mislead by the slant of paper. Quoting from the paper: http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf you will see: | The TCPA chip is not particularly suited to DRM. While it does have | the ability to report signed PCR information, and this information | could be used to prevent playback unless a trusted operating system | and application were in use, this type of scheme would be a | nightmare for content providers to manage. Any change to the BIOS, | the operating system, or the application would change the reported | values. How could content providers recognize which reported PCR | values were good, given the myriad platforms, operating system | versions, and frequent software patches? which clearly admits that the IBM TPM does implement the full set of TCPA functionality as specified in the openly published TCPA spec, and for the purposes of our discussion specifically as you see it does implement the remote attestation feature. (Though the author makes some unimaginative claims that it is "not suited for DRM" because of upgrades may make that difficult to manage. Any sane software architecture built on top of this tech can easily tackle that "problem".) > That's why IBM wants the TPM != TCPA to be loud and clear. That's > why the RIAA can't expect it to solve their "problem". I'd think the more likely reason they want to downplay that TCPA is a DRM enabling technology is because it's bad publicity for a hardware manufacturer.
Re: [IP] Open Source TCPA driver and white papers (fwd)
On Tue, 4 Feb 2003, AARG! Anonymous wrote: > The main features of TCPA are: > > - key storage The IBM TPM does this part. > - secure boot > - sealing > - remote attestation It does *not* do these parts. That's why IBM wants the TPM != TCPA to be loud and clear. That's why the RIAA can't expect it to solve their "problem". Patience, persistence, truth, Dr. mike
Re: [IP] Open Source TCPA driver and white papers (fwd)
Mike Rosing wrote: > Thanks Eugen, It looks like the IBM TPM chip is only a key > store read/write device. It has no code space for the kind of > security discussed in the TCPA. The user still controls the machine > and can still monitor who reads/writes the chip (using a pci bus > logger for example). There is a lot of emphasis on TPM != Palladium, > and TPM != DRM. TPM can not control the machine, and for DRM to work > the way RIAA wants, TPM won't meet their needs. TPM looks pretty useful > as it sits for real practical security tho, so I can see why IBM > wants those !='s to be loud and clear. Note while Safford downplays remote attestation in the rebuttal paper, TCPA specs include remote attestation, which seems on the face of it mostly a DRM enabling feature. So I would say that Ross Anderson, Lucky and other detractors have it right despite this attempted rebuttal. It is true that the secure boot, key storage features are largely user beneficial features. He says "there is currently no CA, but it is unclear if this is the "privacy CA" or the "endoresement CA". In any case it may just be that early revisions of the software they haven't implemented this feature yet. He also mentions "no one asked for it" (the privacy CA to issue certificates for use with the remote attestation feature one presumes). He says you can turn of the endorsement feature. The main features of TCPA are: - key storage - secure boot - sealing - remote attestation the first 3 are user focussed features, and the last is DRM focussed. Sealing also interacts with remote attestation, in that it frustrates software only (as opposed to hardware hacking) attempts to later by pass restrictions imposed on download with remote attestation. Palladium is more flexible and secure in what it can enforce because of the ring-1 because it offers smaller attack surface (the TOR) instead of the whole kernel and all device drivers with TCPA. Safford also argues that it's not fair to critize TCPA based on DRM friendly features because it's tech neutral and anything can be used for good and bad (whatever your point of view). However I'd argue remote attestation as designed has no really plausible non-DRM use and could easily be dropped without loss of user functionality. There are other applications for remote attestation -- for example VPN server trying to assure security of client machines. However these types of applications can still be provided in ways that are useless for DRM -- eg retaining remote attestation but allowing the user with user present test to put the device in a "debug mode" where the bootstrap hashes don't match what is loaded. This kind of thing would be handy for debugging anyway and does not lose user security of remote attestation if it is only configurable via user present test. TCPA doesn't provide user present test (secure path to keyboard and screen as Palladium does), but there is a TCPA bios, and presumably that could have a flag and is (one hopes!) already design to not be software changeable. Similar arguments apply to the Palladium remote attestation function. MS has also made attempts to downplay DRM centric role of Palladium.
Re: [IP] Open Source TCPA driver and white papers (fwd)
On Fri, 24 Jan 2003, David Howe wrote: > Bearing in mind though that DRM/Paladium won't work at all if it can't > trust its hardware - so TPM != Paladium, but TPM (or an improved TPM) is > a prerequisite. Certainly! But this TPM is really nothing more than a dongle attached to the pci bus. It will be straight forward to bypass it for many nefarious operations. Which makes me ahppy, but I suspect it won't make the RIAA very happy :-) Patience, persistence, truth, Dr. mike
Re: [IP] Open Source TCPA driver and white papers (fwd)
at Friday, January 24, 2003 4:53 PM, Mike Rosing <[EMAIL PROTECTED]> was seen to say: > Thanks Eugen, It looks like the IBM TPM chip is only a key > store read/write device. It has no code space for the kind of > security discussed in the TCPA. The user still controls the machine > and can still monitor who reads/writes the chip (using a pci bus > logger for example). There is a lot of emphasis on TPM != Palladium, > and TPM != DRM. TPM can not control the machine, and for DRM to work > the way RIAA wants, TPM won't meet their needs. TPM looks pretty > useful as it sits for real practical security tho, so I can see why > IBM wants those !='s to be loud and clear. Bearing in mind though that DRM/Paladium won't work at all if it can't trust its hardware - so TPM != Paladium, but TPM (or an improved TPM) is a prerequisite.
Re: [IP] Open Source TCPA driver and white papers (fwd)
On Fri, 24 Jan 2003, Eugen Leitl wrote: > -- Forwarded message -- > Date: Fri, 24 Jan 2003 02:29:27 -0500 > From: Dave Farber <[EMAIL PROTECTED]> > To: ip <[EMAIL PROTECTED]> > Subject: [IP] Open Source TCPA driver and white papers > > > -- Forwarded Message > From: David Safford <[EMAIL PROTECTED]> > Date: Tue, 21 Jan 2003 12:05:39 -0500 > To: [EMAIL PROTECTED] > Subject: [open-source] Open Source TCPA driver and white papers > > > IBM has released a Linux device driver under GPL for its TCPA chip (TPM). > The driver is available at > http://www.research.ibm.com/gsal/tcpa/ > > This page also has links to two papers, one presenting positive uses > of the chip, and the second rebutting misinformation about the chip. Thanks Eugen, It looks like the IBM TPM chip is only a key store read/write device. It has no code space for the kind of security discussed in the TCPA. The user still controls the machine and can still monitor who reads/writes the chip (using a pci bus logger for example). There is a lot of emphasis on TPM != Palladium, and TPM != DRM. TPM can not control the machine, and for DRM to work the way RIAA wants, TPM won't meet their needs. TPM looks pretty useful as it sits for real practical security tho, so I can see why IBM wants those !='s to be loud and clear. Patience, persistence, truth, Dr. mike
[IP] Open Source TCPA driver and white papers (fwd)
-- Forwarded message -- Date: Fri, 24 Jan 2003 02:29:27 -0500 From: Dave Farber <[EMAIL PROTECTED]> To: ip <[EMAIL PROTECTED]> Subject: [IP] Open Source TCPA driver and white papers -- Forwarded Message From: David Safford <[EMAIL PROTECTED]> Date: Tue, 21 Jan 2003 12:05:39 -0500 To: [EMAIL PROTECTED] Subject: [open-source] Open Source TCPA driver and white papers IBM has released a Linux device driver under GPL for its TCPA chip (TPM). The driver is available at http://www.research.ibm.com/gsal/tcpa/ This page also has links to two papers, one presenting positive uses of the chip, and the second rebutting misinformation about the chip. These papers, combined with the Linux driver and the TCPA specification at http://www.trustedcomputing.org, give everyone the ability to test an actual chip (such as in the Thinkpad T30), to see for themselves what it can, and cannot do. Note: the papers and driver do not discuss Palladium. Palladium and TCPA are two separate topics. dave safford [EMAIL PROTECTED] -- End of Forwarded Message - You are subscribed as [EMAIL PROTECTED] To unsubscribe or update your address, click http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/
