Just because some cars have anti-theft devices that can be defeated in
seconds doesn't make all auto anti-theft devices useless.
so you have currently have an environment that has no protection and
everything is totally wide open.
lets say a hardware chip that currently has no tamper
- Original Message -
From: Ben Laurie [EMAIL PROTECTED]
The important part for this, is that TCPA has no key until it has an
owner,
and the owner can wipe the TCPA at any time. From what I can tell this
was
designed for resale of components, but is perfectly suitable as a point
of
Joseph Ashwood wrote:
- Original Message -
From: Ben Laurie [EMAIL PROTECTED]
Joseph Ashwood wrote:
There is nothing stopping a virtualized version being created.
What prevents this from being useful is the lack of an appropriate
certificate for the private key in the TPM.
This is going to be a very long, and very boring message. But it should
highlight why we have differing opinions about so very many capabilities of
the TCPA system. For the sake of attempting to avoid supplying too little
information, I have simply searched for the term and will make comments on
Joe Ashwood writes:
Actually that does nothing to stop it. Because of the construction of TCPA,
the private keys are registered _after_ the owner receives the computer,
this is the window of opportunity against that as well.
Actually, this is not true for the endoresement key, PUBEK/PRIVEK,
Adam Back writes:
So there are practical limits stemming from realities to do with code
complexity being inversely proportional to auditability and security,
but the extra ring -1, remote attestation, sealing and integrity
metrics really do offer some security advantages over the current
Phew... the document is certainly tortuous, and has a large number of
similarly and confusingly named credentials, certificates and keys,
however from what I can tell this is what is going on:
Summary: I think the endorsement key and it's hardware manufacturers
certificate is generated at
I would like to draw your attention to a relatively new document:
http://ftp.ietf.org/internet-drafts/draft-housley-ccm-mode-00.txt
It contains a specification for an authenticated encryption mode. It was
designed fro use with AES, but, of course, it will work with any 128-bit
block
(Forwarded from DMCA Activists list. Article text pasted
below. -- Seth)
Original Message
Date: 15 Aug 2002 12:30:02 -0400
From: Matthew Caron [EMAIL PROTECTED]
To: DMCA [EMAIL PROTECTED]
http://www.guardian.co.uk/Archive/Article/0,4273,4477138,00.html
In short:
1.) Guy
Russell Nelson[SMTP:[EMAIL PROTECTED]] writes:
You're wearing your programmer's hat when you say that. But the
problem isn't programming, but is instead economic. Switch hats. The
changes that you list above may or may not offer some security
advantages. Who cares? What really matters
bear wrote:
... I have one box with all the protection I want:
it's never connected to the net at all. I have another box
with all the protection that I consider practical for email
and web use. Both run only and exactly the software I have
put on them,
That is trusted computing
I think a number of the apparent conflicts go away if you carefully
track endorsement key pair vs endorsement certificate (signature on
endorsement key by hw manufacturer). For example where it is said
that the endorsement _certificate_ could be inserted after ownership
has been established (not
12 matches
Mail list logo
