Re: TPM disk crypto

2006-10-13 Thread Anne Lynn Wheeler
cyphrpunk wrote:
 1. The issue is still moot at present. We are a long way from where
 open, public, remote attestion will be possible. See this diagram from
 the Trousers open-source TPM software stack project which shows which
 pieces are still missing:
 
 http://trousers.sourceforge.net/remote_attestation_deps.png
 

so i did do fab process and associated infrastructure for tpm-like chips
that recorded public key at manufacturing time. this came up in recent
thread on trusting chips and/or knowing integrity level of chips
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#2 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#3 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#5 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP:
snake oil or good idea?

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-13 Thread Ivan Krstić
Travis H. wrote:
 I can validate everything else, but as long as the BIOS is
 motherboard-specific and closed source, I don't see why I should trust
 it.  We need to get rid of this legacy crud.  LinuxBIOS is a good step
 but unfortunately it is only supported on a few motherboards. 

We're shipping LinuxBIOS on the One Laptop per Child machines.

 No BIOS
 I know of has a semblance of security, given temporary physical access
 to the machine.

I came up with a scheme that lets us do a secure BIOS without a TPM;
bypassing it without a PLCC would be extremely difficult. I'm not yet
certain if we'll end up shipping a PLCC socket on the final hardware,
but if not, I suspect you'd be hard-pressed to do much to the BIOS
protection even with physical access, short of un-soldering and
re-soldering a different SPI flash chip to the motherboard. That was
explicitly not part of my threat model.

-- 
Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-13 Thread Ivan Krstić
Alexander Klimov wrote:
 Since a regular installation
 should not change ``reported OS hash,'' TPM will not be able to detect
 the difference. Am I missing something?

You're missing the marketing value of saying this piece of hardware,
that you probably wouldn't otherwise want in your machine since it makes
sure that the machine can be trusted /against/ you, is great! Because it
protects you against trojans! And everyone wants to be safe from
trojans, right?.

 Btw, how the TCG allows to regularly change the kernel for security
 patches and still keep the same ``reported hash''?

The Microsoft guy presenting BitLocker at HITB last month mentioned
this, but glossed over it without explaining. He did seem to indicate
that they had some solution, but didn't provide details, IIRC.

-- 
Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-13 Thread Ivan Krstić
Kuehn, Ulrich wrote:
 Who is we? In the case of my own system I payed for (so speaking
 for myself) I would like to have such a mechanism to have the system
 prove to me before login that it is not tampered with. The TCG
 approach does not provide this. 

What does prove mean here? Does having a hash of the system state for
visual inspection before boot do it?

-- 
Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-13 Thread cyphrpunk

On 10/10/06, Adam Back [EMAIL PROTECTED] wrote:

I think the current CPUs / memory managers do not have the ring -1 /
curtained memory features, but already a year ago or more Intel and
AMD were talking about these features.  So its possible the for
example hypervisor extra virtualization functionality in recent
processors ties with those features, and is already delivered?  Anyone
know?


Intel LaGrande Technology is supposed to ship soon and combines
virtualization with TPM integration so you can load what they call a
MVMM: a measured virtual machine monitor. Measured means the hash
goes securely to the TPM so it can attest to it, and third parties can
verify what VMM you are running. Then the security properties would
depend on what the VMM enforces. The MVMM runs in what you might call
ring -1, while the OS running in ring 0 has only virtualized access to
certain system resources like page tables.

One thing the MVMM could do is to measure and attest to OS properties.
Then if you patched the OS to bypass a signed-driver check, it might
not work right.

One question that was raised is how these systems can be robust
against OS upgrades and such. It would seem that ultimately this will
require attestation to be based on a signing key rather than the code
fingerprint. Rather than hashing the code it loads, the MVMM would
verify that the code is signed by a certain key, and hash the key,
sending that to the TPM. Then any code signed by the same key could
produce the same attestation and have access to the same sealed data.

The TCG infrastructure working group is supposed to standardize what
kinds of attestions will be used and what they will mean.

CP

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-13 Thread James A. Donald

James A. Donald:
 Well obviously I trust myself, and do not trust
 anyone else all that much, so if I am the user, what
 good is trusted computing?

 One use is that I can know that my operating system
 has not changed behind the scenes, perhaps by a
 rootkit, know that not only have I not changed the
 operating system, but no one else has changed the
 operating system.

Alexander Klimov wrote:
 The argument that TPM can prevent trojans seems to
 imply that the trojans are installed by modification
 of raw storage while the OS is offline.

No it does not.

 Btw, how the TCG allows to regularly change the kernel
 for security patches and still keep the same
 ``reported hash''?

It can report that the hash is a value that has
been blessed by signed software - and can report that
its list of reputable signing authorities is blessed by
Microsoft, and does not include me.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-13 Thread cyphrpunk

Here is a posting from the cypherpunks mailing list describing the
capabilities of Intel's new virtualization/TPM technology. Gets a bit
ranty but still good information.

CP

-- Forwarded message --
From: Anonymous Remailer (austria) [EMAIL PROTECTED]
Date: Fri, 29 Sep 2006 03:25:57 +0200 (CEST)
Subject: Palladium is back. And this time, it's...
To: [EMAIL PROTECTED]

In the past few weeks new information has come out on the Trusted
Computing (TC) front which provides clues to where this powerful
and controversial technology may be heading.  Much of this has come
from Intel, which has revealed more information about their LaGrande
technology, now un-codenamed to Trusted Execution Technology.  A good
source of links is the Hack the Planet blog, http://wmf.editthispage.com/
- scroll down to the September 25 entry.

LaGrande was originally designed as the hardware support for Microsoft's
now-defunct Palladium, relating to the differences between Palladium and
TCPA (now called TCG).  Both technologies relied on the TPM chip to take
measurements of running software, report those measurements remotely via
trusted attestations, and lock encrypted data to those measurements so
that other software configurations could not decrypt it.  These are the
core capabilities which give TC its power.  But there were important
differences in the two approaches.

TCPA was focused on a measured boot process.  As the system boots,
each stage would measure (i.e. hash into the TPM) the next stage before
switching control to it.  At the end of this process the TPM's Platform
Configuration Registers would hold a fingerprint of the software
configuration that had booted.  With a TPM-aware OS the PCRs could be
further updated as each program launches to keep an up-to-date picture
of what is running.

Palladium instead wanted to be able to switch to trusted mode in mid
stream, after booting; and wanted to continue to run the legacy OS while
new applications ran in the trusted area.  LaGrande Technology (LT,
now TET), in conjunction with new TPM capabilities offered in the 1.2
chips now available, would provide the support for this late launch
concept.  Palladium is now gone but Intel has continued to develop
LaGrande and has now released documentation on how it will work, at
http://www.intel.com/technology/security/.

Late launch starts with the OS or the BIOS executing one of the new
LT instructions.  This triggers a complex sequence of operations
whose purpose is to load, measure (ie hash into the TPM) and launch a
hypervisor, that is, a Virtual Machine Monitor (VMM).  The hypervisor can
then repackage the state of the launching OS as a Virtual Machine (VM)
and transfer control back to it.  The OS has now become transparently
virtualized and is running on top of the VMM.  The VMM can then launch
secure VMs which execute without being molested by the legacy OS.

Another enhancement of LT is that the chipset can be programmed to prevent
DMA access to specified memory areas.  This will close a loophole in
existing VMM systems, that VMs can program DMA devices to overwrite other
VMs' memory.  This protection is necessary for the TC goal of protected
execution environments.

Both VMWare and Xen are getting involved with this technology.  As the
blog entry above says, Intel donated code to Xen a few days ago to support
much of this functionality, so that Xen will be able to launch in this
way on TET machines.  Another link from the blog entry is an amazing
Intel presentation showing how excited the NSA is about this technology.
Within a couple of years they will be able to acquire Commercial Off
the Shelf (COTS) systems configured like this, that will allow running
multiple instances of OS's with different security classifications.
The slides show a system running two versions of Windows, one for Secret
and one for Top Secret data, appearing in separate windows on the screen.
Xen or VMWare with TET will be able to do this very soon if not already.

Here's Intel's description of how software might be configured to use
this capability, from their Trusted Execution Technology Architectural
Overview linked from the LaGrande page above:


Trusted Execution Technology provides a set of capabilities that can be
utilized in many different operating environments (Figure 2). One proposed
architecture provides a protection model similar to the following:

A standard partition that provides an execution environment that is
identical to today's IA-32 environment. In this environment, users will be
able to run applications and other software just as they do on today's
PC. The standard partition's obvious advantage is that it preserves
the value of the existing code base (i.e. existing software does not
need modification to run in the standard partition) and potential future
software that is less security conscious. Unfortunately, it also retains
the inherent vulnerabilities of today's environment.

A protected partition provides a 

RE: TPM disk crypto

2006-10-13 Thread Kuehn, Ulrich
 From: Ivan Krstić [mailto:[EMAIL PROTECTED] 
 Kuehn, Ulrich wrote:
  Who is we? In the case of my own system I payed for (so 
 speaking for 
  myself) I would like to have such a mechanism to have the 
 system prove 
  to me before login that it is not tampered with. The TCG 
 approach does 
  not provide this.
 
 What does prove mean here? Does having a hash of the system 
 state for visual inspection before boot do it?
 
Well, reliably obtaining the end of a hash chain would do, but it would be very 
inconvenient to compare that manually (visually) to a hash written on a piece 
of paper in my wallet. That is not user-friendly. However, if the system 
provided a possibility to reliably stop the boot process when something is 
changed, that would do.

With reliably stopping the boot process I mean the following: Given that stage 
i of the process is running, it takes the hash of the next stage, compares that 
to an expected value. If they match, the current stage extends the TPM register 
(when also running the TCG stuff), and executes the next stage. If the computed 
and expected hashes do not match, the machine goes into a predetermined halt 
state. 

Predetermined means that the system administrator (on behalf of the system 
owner) can determine the expected hash value. 

I hope this makes it clear what I meant in the text quoted above. 

To implement this the TCG-preBIOS would need to implement this halt state, 
possibly along with some other additional features like where to store the 
expected hashes etc.

Cheers,
Ulrich

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-13 Thread cyphrpunk

On 10/13/06, Kuehn, Ulrich [EMAIL PROTECTED] wrote:

With reliably stopping the boot process I mean the following: Given that
stage i of the process is running, it takes the hash of the next stage,
compares that to an expected value. If they match, the current stage extends
the TPM register (when also running the TCG stuff), and executes the next
stage. If the computed and expected hashes do not match, the machine goes
into a predetermined halt state.

Predetermined means that the system administrator (on behalf of the system
owner) can determine the expected hash value.


You don't need the TPM for this. You could imagine a boot process
where each stage hashed the next stage, and refused to proceed if it
didn't match an expected value. One question though is how you prevent
malware from changing these expected values, even potentially
reflashing the BIOS.

A student project at Dartmouth a few years ago,
enforcer.sourceforge.net, worked like this. It could also optionally
use a TPM but didn't have to. The project appears to be abandoned but
the supervising professor, Sean Smith, in his book Trusted Computing
Platforms says that new students are bringing it up to date, getting
it working with newer kernels including selinux support.

Here's the Enforcer description. Nice piece of work. Hopefully they'll
release an updated version now that TPMs are more common.

The Enforcer is a Linux Security Module designed to improve integrity
of a computer running Linux by ensuring no tampering of the file
system. It can interact with TCPA hardware to provide higher levels of
assurance for software and sensitive data.

It can check, as every file is opened, if the file has been changed,
and take an admin specified action when it detects tampering. The
actions can be any combination of log the error, deny access to the
file, panic the system, or several operations that work with the TPM.

The Enforcer can also work with the TPM to store the secret to an
encrypted loopback file system, and unmount this file system when a
tampered file is detected. The secret will not be accessible to mount
the loopback file system until the machine has been rebooted with
untampered files. This allows sensitive data to be protected from an
attacker.

The Enforcer can also bind specific files so that only specific
applications can access them (for example, only apache is allowed to
access apache's secret ssl key). This means that even if someone
compromises your system, the attacker will not be able to steal
critical files.

Finally, the Enforcer can make sure that no files added to
directories after its database is built are allowed to be accessed.

One thing they worked hard on in the design is the balance between
detecting malicious changes, and allowing necessary changes for
maintenance and upgrades. They identified different classes of
components that were updated seldom, occasionally or frequently, and
architected the system to provide an appropriate degree of checking
for each category. The academic paper is here:

http://www.cs.dartmouth.edu/~sws/abstracts/mswm03.shtml

CP

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-12 Thread Alexander Klimov
On Mon, 9 Oct 2006 kkursawe at esat.kuleuven.ac.be wrote:
  IIUC, TPM is pointless for disk crypto: if your laptop is stolen the
  attacker can reflash BIOS and bypass TPM.

 According to TCG Specification, the first part of the BIOS (called
 Core Root of Trust for Measurement) should be non-flashable; this
 part then checksums the rest of the BIOS, option ROMS etc. and
 reports those to the TPM. I don't know how this is done in devices
 currently sold, but at least it should not be trivial to reprogram
 that part of the BIOS.

Even if BIOS is real ROM, but there are some inter-chip links between
ROM, CPU, and TPM, it seems possible for an attacker with an iron and
FPGAs to trick the TPM to reveal the secret. That is against
highly-motivated attacker TPM does not give really more protection
than truecrypt, but for a casual attacker (who is just curious what is
on a stolen laptop) even truecrypt is enough.

-- 
Regards,
ASK

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: TPM disk crypto

2006-10-12 Thread Kuehn, Ulrich
 From: James A. Donald [mailto:[EMAIL PROTECTED] 
 Sent: Dienstag, 10. Oktober 2006 06:40
 
 What we want is that a bank client can prove to the bank it 
 is the real client, and not trojaned.  What the evil guys at 
 RIAA want is that their music player can prove it is their 
 real music player, and not hacked by the end user. Having a 
 system that will only boot up in a known state is going to 
 lead to legions of unhappy customers who find their system 
 does not come up at all.
 

Who is we? In the case of my own system I payed for (so speaking for myself) 
I would like to have such a mechanism to have the system prove to me before 
login that it is not tampered with. The TCG approach does not provide this. Oh, 
and predetermined means that the machine admin can declare to which known state 
the system is going to boot. 

From a company point of view it might be interesting to make sure the 
employees have systems that come up to a predetermined state, or not at all, 
so when infected this turns up at next boot so that the admin can fix it.
Here the TCG approach would also be helpful as the remote attestation against a 
central server (or a number of them) can help. 

And for the RIAA guys, they have no business on the machine I did pay for (!), 
as long as I do not infringe their copyright. Assumed innocent until proven 
guilty! On the other hand, there has been an infamous record company that 
miserably failed  to ensure their components on consumers' computers are _not_ 
a security risk. 

Ulrich

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-12 Thread Adam Back
I was suspecting that as DRM at least appears to one of the main
motivators (along side trojan/malware protection) for trustworthy
computing that probably you will not be able to put the TPM into debug
mode (ie manipulate code without affecting the hash attested in debug
mode).  Ability to do so breaks DRM.

Also bear in mind the vista model where it has been described that
inserting an unsigned device driver into the kernel will disable some
media playback (requiring DRM).  And also the secure (encrypted) path
between trusted agent and video/audio card, and between video/audio
card and monitor/speakers.  The HDMI spec has these features, and you
can already buy HDMI cards and monitors (though I dont know if they
have the encryption features implemented/enabled).

I think generally full user control model will not be viewed
compatible.  Ie there will be a direct conflict between user ability
to debug attested apps and DRM.

So then enters the possibility to debug all apps except special ones
flagged as DRM, but if that technical ability is there, you wont have
wait long for it to be used for all things: file formats locked to
editors, per processor encrypted binaries, rented by the hour software
you cant debug or inspect memory space of etc.

I think the current CPUs / memory managers do not have the ring -1 /
curtained memory features, but already a year ago or more Intel and
AMD were talking about these features.  So its possible the for
example hypervisor extra virtualization functionality in recent
processors ties with those features, and is already delivered?  Anyone
know?

The device driver signing thing is clearly bypassable without a TPM,
and we know TPMs are not widely available at present.  (All that is
required is to disable or nop out the driver signature verification in
the OS; or replace the CA or cert it is verified against with your own
and sign your own drivers).  How long until that OS binary patch is
made?

Adam

On Tue, Oct 10, 2006 at 12:56:07PM +0100, Brian Gladman wrote:
 I haven't been keeping up to date with this trusted computing stuff over
 the last two years but when I was last involved it was accepted that it
 was vital that the owner of a machine (not necessarily the user) should
 be able to do the sort of things you suggest and also be able to exert
 ultimate control over how a computing system presents itself to the
 outside world.
 
 Only in this way can we undermine the treacherous computing model of
 trusted machines with untrusted owners and replace it with a model in
 which trust in this machine requires trust in its owner on which real
 information security ultimately depends (I might add that even this
 model has serious potential problems when most machine owners do not
 understand security).
 
 Does anyone know the current state of affairs on this issue within the
 Trusted Computing Group (and the marketed products of its members)?

 Adam Back wrote:
  So the part about being able to detect viruses, trojans and attest
  them between client-server apps that the client and server have a
  mutual interest to secure is fine and good.
  
  The bad part is that the user is not given control to modify the hash
  and attest as if it were the original so that he can insert his own
  code, debug, modify etc.
  
  (All that is needed is a debug option in the BIOS to do this that only
  the user can change, via BIOS setup.)

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-12 Thread Alexander Klimov
On Mon, 9 Oct 2006, James A. Donald wrote:

 Well obviously I trust myself, and do not trust anyone else all that
 much, so if I am the user, what good is trusted computing?

 One use is that I can know that my operating system has not changed
 behind the scenes, perhaps by a rootkit, know that not only have I
 not changed the operating system, but no one else has changed the
 operating system.

The argument that TPM can prevent trojans seems to imply that the
trojans are installed by modification of raw storage while the OS is
offline. Probably, this can be a case for malicious internet-cafes,
but 99.9% of trojans on home PCs of normal people are installed when
the OS is active (0.1% is for trojans installed by law enforcement).
(Of course, an attacker with physical access can install physical
trojans: hardware keylogger and camera.) Since a regular installation
should not change ``reported OS hash,'' TPM will not be able to detect
the difference. Am I missing something?

Btw, how the TCG allows to regularly change the kernel for security
patches and still keep the same ``reported hash''?

-- 
Regards,
ASK

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-12 Thread John Gilmore
 What we want is that a bank client can prove to the bank
 it is the real client, and not trojaned.  What the evil
 guys at RIAA want is that their music player can prove
 it is their real music player, and not hacked by the end
 user. Having a system that will only boot up in a known
 state is going to lead to legions of unhappy customers
 who find their system does not come up at all.

Having remote attestation that provides signed checksums of every
stage of the startup process, which are checked by guys at the RIAA or
guys at the bank, will lead to legions of unhappy customers who find
their system boots fine, but is denied access to both the bank and the
music store.  (Seventy thousand totally valid configurations are not
going to be checked and confirmed by either one.)  But their system
will access the Darknet just fine.

John

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-12 Thread Travis H.

On 10/9/06, Adam Back [EMAIL PROTECTED] wrote:

The bad part is that the user is not given control to modify the hash
and attest as if it were the original so that he can insert his own
code, debug, modify etc.

(All that is needed is a debug option in the BIOS to do this that only
the user can change, via BIOS setup.)


Actually, it's the BIOS I don't trust.

I can validate everything else, but as long as the BIOS is
motherboard-specific and closed source, I don't see why I should trust
it.  We need to get rid of this legacy crud.  LinuxBIOS is a good step
but unfortunately it is only supported on a few motherboards.  No BIOS
I know of has a semblance of security, given temporary physical access
to the machine.

BTW, the x86 microcode updates are performed by the BIOS IIRC and
require no hardware settings.  Is there any reason you can't update
the processor microcode later on in the boot process?
--
The obvious mathematical breakthrough would be the development of an
easy way to factor large prime numbers.'' [sic] -- Bill Gates  --
URL:http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-12 Thread cyphrpunk

On 10/10/06, Brian Gladman [EMAIL PROTECTED] wrote:

I haven't been keeping up to date with this trusted computing stuff over
the last two years but when I was last involved it was accepted that it
was vital that the owner of a machine (not necessarily the user) should
be able to do the sort of things you suggest and also be able to exert
ultimate control over how a computing system presents itself to the
outside world.

Only in this way can we undermine the treacherous computing model of
trusted machines with untrusted owners and replace it with a model in
which trust in this machine requires trust in its owner on which real
information security ultimately depends (I might add that even this
model has serious potential problems when most machine owners do not
understand security).

Does anyone know the current state of affairs on this issue within the
Trusted Computing Group (and the marketed products of its members)?


1. The issue is still moot at present. We are a long way from where
open, public, remote attestion will be possible. See this diagram from
the Trousers open-source TPM software stack project which shows which
pieces are still missing:

http://trousers.sourceforge.net/remote_attestation_deps.png

There is actually another important piece missing from that diagram,
namely operating system support. At present the infrastructure would
only allow attestation at the OS-boot level, i.e. you could prove what
OS you booted. It's a big step from there to proving that you are
running a safe application, unless the service would require you to
reboot your machine into their OS every time you want to run their
client.

2. Not an insider, but I haven't heard anything about serious efforts
to implement Owner Override or similar proposals. Instead, the
response seems to be to wait and hope all that fuss blows over.

3. What little evidence exists suggests that TCG is going in the
opposite direction. The 1.2 TPM is designed to work with Intel's
Lagrange Technology which will add improved process isolation and late
launch. This will make it possible to attest at the level of
individual applications, and provide protection against the local user
that a plain TPM system can't manage. 1.2 also adds a
cryptographically blinded attestation mode that gets rid of the ugly
privacy ca which acted as a TTP in 1.1, and which will make it
easier to move towards attestation.

4. Software remains the biggest question mark, and by software I mean
Microsoft. They have said nothing about attestation support in Vista.
Given the hostile response to Palladium I doubt there is much
enthusiasm about jumping back into that crocodile pit. It doesn't seem
to be stopping HD-DVD from moving forward, even though there is no
credible probability of an attestation feature appearing in the time
frame needed for these new video product introductions.

Without a driving market force to introduce attestation, and
tremendous social resistance, the status quo will probably prevail for
another couple of years. By that time LT will be available, TPMs will
be nearly universal but used only for improved local security, and
perhaps some tentative steps into attestation will appear. The initial
version might be targeted at corporate VPNs which will prevent mobile
employees from connecting unless their laptops attest as clean. This
would be an uncontroversial use of the technology except for its
possible implications as a first step towards wider use.

Whether we will eventually ever see the whole model, with attestation,
process isolation, sealed storage, and trusted i/o path all leading to
super-DRM, is very much an open question. So many barriers exist
between here and there that it seems unlikely that this will be seen
by anyone as the right solution to that problem, by then.

CP

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-10 Thread James A. Donald

--
Kuehn, Ulrich wrote:
 However, this is the big problem with the TPM
 according to the TCG spec. While you can remotely
 verify that the system came up according to what you
 installed there, you have no means to force it to
 either come up the way you want, or to be in a clear
 error state. That is the huge difference between the
 verifiable booting the TPM provides and secure
 booting, which would run only predetermined software.

 I assume that the TCG chose not to implement the
 latter due to fear of public bashing...

What we want is that a bank client can prove to the bank
it is the real client, and not trojaned.  What the evil
guys at RIAA want is that their music player can prove
it is their real music player, and not hacked by the end
user. Having a system that will only boot up in a known
state is going to lead to legions of unhappy customers
who find their system does not come up at all.


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 mzJSAlA4uoeaqcIPwxmdSTaMGpCr10BSXet2rKo+
 4C0qq8mGmz37gK89YinlEpVVumD1TtkcDOd8iHHGh

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-10 Thread Brian Gladman
Adam Back wrote:

 So the part about being able to detect viruses, trojans and attest
 them between client-server apps that the client and server have a
 mutual interest to secure is fine and good.
 
 The bad part is that the user is not given control to modify the hash
 and attest as if it were the original so that he can insert his own
 code, debug, modify etc.
 
 (All that is needed is a debug option in the BIOS to do this that only
 the user can change, via BIOS setup.)

I haven't been keeping up to date with this trusted computing stuff over
the last two years but when I was last involved it was accepted that it
was vital that the owner of a machine (not necessarily the user) should
be able to do the sort of things you suggest and also be able to exert
ultimate control over how a computing system presents itself to the
outside world.

Only in this way can we undermine the treacherous computing model of
trusted machines with untrusted owners and replace it with a model in
which trust in this machine requires trust in its owner on which real
information security ultimately depends (I might add that even this
model has serious potential problems when most machine owners do not
understand security).

Does anyone know the current state of affairs on this issue within the
Trusted Computing Group (and the marketed products of its members)?

   Brian Gladman


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: TPM disk crypto

2006-10-09 Thread Kuehn, Ulrich
 
 From: Erik Tews [mailto:[EMAIL PROTECTED] 
 Sent: Donnerstag, 5. Oktober 2006 23:52
 
[...]
 
 Later, you can remotely query your system and get a report 
 what has been bootet on your system. You can do this query 
 using a java application and tpm4java.
 

However, this is the big problem with the TPM according to the TCG spec. While 
you can remotely verify that the system came up according to what you installed 
there, you have no means to force it to either come up the way you want, or to 
be in a clear error state. That is the huge difference between the verifiable 
booting the TPM provides and secure booting, which would run only predetermined 
software.

I assume that the TCG chose not to implement the latter due to fear of public 
bashing...

Ulrich

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-09 Thread Alexander Klimov
On Fri, 6 Oct 2006, Erik Tews wrote:
  And the TPM knows that your BIOS has not lied about the checksum of grub
  how?

 The TPM does not know that the BIOS did not lie about the checksum of
 grub or any other bios component.

 What you do is, you trust your TPM and your BIOS that they never lie to
 you, because they are certified by the manufature of the system and the
 tpm. (This is why it is called trusted computing)

IIUC, TPM is pointless for disk crypto: if your laptop is stolen the
attacker can reflash BIOS and bypass TPM. Moreover, TPM is actually
bad for disk crypto: without it you lose your data only if your HDD
dies, now you lose your data if your HDD dies *or* if you motherboard
dies. If the user is not experienced in BIOS reflashing, they also
lose their data if OS crashes and refuses to boot (not uncommon for
some common OSes).

-- 
Regards,
ASK

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-09 Thread James A. Donald

Erik Tews wrote:

What you do is, you trust your TPM and your BIOS that they never lie to
you, because they are certified by the manufature of the system and the
tpm. (This is why it is called trusted computing)

So if you don't trust your hardware and your manufactor, trusted
computing is absolutely worthless for you. But if you trust a
manufactor, the manufactor trusts the tpms he has build and embedded in
some systems, and you don't trust a user that he did not boot a modified
version of your operating system, you can use these components to find
out if the user is lieing.


Well obviously I trust myself, and do not trust anyone else all that 
much, so if I am the user, what good is trusted computing?


One use is that I can know that my operating system has not changed 
behind the scenes, perhaps by a rootkit, know that not only have I not 
changed the operating system, but no one else has changed the operating 
system.


Further, I can know that a known program on a known operating system has 
not been changed by a trojan.


So if I have a login and banking client program, which communicates to 
me over a trusted path, I can know that the client is the unchanged 
client running on the unchanged operating system, and has not been 
modified or intercepted by some trojan.


Further, the bank can know this, and can just not let me login if there 
is something funny about client program or the OS.



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-09 Thread Adam Back
So the part about being able to detect viruses, trojans and attest
them between client-server apps that the client and server have a
mutual interest to secure is fine and good.

The bad part is that the user is not given control to modify the hash
and attest as if it were the original so that he can insert his own
code, debug, modify etc.

(All that is needed is a debug option in the BIOS to do this that only
the user can change, via BIOS setup.)

Adam

On Mon, Oct 09, 2006 at 08:03:40PM +1000, James A. Donald wrote:
 Erik Tews wrote:
 What you do is, you trust your TPM and your BIOS that they never lie to
 you, because they are certified by the manufature of the system and the
 tpm. (This is why it is called trusted computing)
 
 So if you don't trust your hardware and your manufactor, trusted
 computing is absolutely worthless for you. But if you trust a
 manufactor, the manufactor trusts the tpms he has build and embedded in
 some systems, and you don't trust a user that he did not boot a modified
 version of your operating system, you can use these components to find
 out if the user is lieing.
 
 Well obviously I trust myself, and do not trust anyone else all that 
 much, so if I am the user, what good is trusted computing?
 
 One use is that I can know that my operating system has not changed 
 behind the scenes, perhaps by a rootkit, know that not only have I not 
 changed the operating system, but no one else has changed the operating 
 system.
 
 Further, I can know that a known program on a known operating system has 
 not been changed by a trojan.
 
 So if I have a login and banking client program, which communicates to 
 me over a trusted path, I can know that the client is the unchanged 
 client running on the unchanged operating system, and has not been 
 modified or intercepted by some trojan.
 
 Further, the bank can know this, and can just not let me login if there 
 is something funny about client program or the OS.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-09 Thread Martin Hermanowski




Alexander Klimov schrieb:

  On Fri, 6 Oct 2006, Erik Tews wrote:
  
  

  And the TPM knows that your BIOS has not lied about the checksum of grub
how?
  

The TPM does not know that the BIOS did not lie about the checksum of
grub or any other bios component.

What you do is, you trust your TPM and your BIOS that they never lie to
you, because they are certified by the manufature of the system and the
tpm. (This is why it is called trusted computing)

  
  
IIUC, TPM is pointless for disk crypto: if your laptop is stolen the
attacker can reflash BIOS and bypass TPM. Moreover, TPM is actually
bad for disk crypto: without it you lose your data only if your HDD
dies, now you lose your data if your HDD dies *or* if you motherboard
dies. If the user is not experienced in BIOS reflashing, they also
lose their data if OS crashes and refuses to boot (not uncommon for
some common OSes).

  

There is a great risk of data loss if the TPM protection is badly
implemented. You can, however, store an encrypted key in your (not
encrypted) hard disk, and save the decryption key both inside the TPM
(bound to valid bios/boot loader/Kernel/OS PCR values) *and* in a
second place for emergency recovery (like a memory stick in a safe).

This way, the data on the hard disk can only be decrypted, if the
unaltered operating system is used - the TPM will not decrypt the
bound data if the system state changed. Of course, after reflashing
your bios, you need to use your second key credential (once).

-- 
Martin Hermanowski
http://martin.hermanowski.name
https://www.openbc.com/hp/Martin_Hermanowski/





signature.asc
Description: OpenPGP digital signature


Re: TPM disk crypto

2006-10-08 Thread Thor Lancelot Simon
On Thu, Oct 05, 2006 at 11:51:49PM +0200, Erik Tews wrote:
 Am Donnerstag, den 05.10.2006, 16:25 -0500 schrieb Travis H.:
  On 10/2/06, Erik Tews [EMAIL PROTECTED] wrote:
   Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.:
Anyone have any information on how to develop TPM software?
http://tpm4java.datenzone.de/
   Using this lib, you need less than 10 lines of java-code for doing some
   simple tpm operations.
  
  Interesting, but not what I meant.  I want to program the chip to verify
  that the BIOS, boot sector, root partition conform to *my* specification.
  
 You can do that (at least in theory).
 
 First, you need a system with tpm. I assume you are running linux. Then
 you boot your linux-kernel and an initrd using the trusted grub
 bootloader. Your bios will report the checksum of trusted grub to the
 tpm before giving control to your grub bootloader.

And the TPM knows that your BIOS has not lied about the checksum of grub
how?

Thor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-08 Thread Erik Tews
Am Freitag, den 06.10.2006, 17:29 -0400 schrieb Thor Lancelot Simon:
 On Thu, Oct 05, 2006 at 11:51:49PM +0200, Erik Tews wrote:
  Am Donnerstag, den 05.10.2006, 16:25 -0500 schrieb Travis H.:
   On 10/2/06, Erik Tews [EMAIL PROTECTED] wrote:
Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.:
 Anyone have any information on how to develop TPM software?
 http://tpm4java.datenzone.de/
Using this lib, you need less than 10 lines of java-code for doing some
simple tpm operations.
   
   Interesting, but not what I meant.  I want to program the chip to verify
   that the BIOS, boot sector, root partition conform to *my* specification.
   
  You can do that (at least in theory).
  
  First, you need a system with tpm. I assume you are running linux. Then
  you boot your linux-kernel and an initrd using the trusted grub
  bootloader. Your bios will report the checksum of trusted grub to the
  tpm before giving control to your grub bootloader.
 
 And the TPM knows that your BIOS has not lied about the checksum of grub
 how?

The TPM does not know that the BIOS did not lie about the checksum of
grub or any other bios component.

What you do is, you trust your TPM and your BIOS that they never lie to
you, because they are certified by the manufature of the system and the
tpm. (This is why it is called trusted computing)

So if you don't trust your hardware and your manufactor, trusted
computing is absolutely worthless for you. But if you trust a
manufactor, the manufactor trusts the tpms he has build and embedded in
some systems, and you don't trust a user that he did not boot a modified
version of your operating system, you can use these components to find
out if the user is lieing.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Re: TPM disk crypto

2006-10-06 Thread Travis H.

On 10/2/06, Erik Tews [EMAIL PROTECTED] wrote:

Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.:
 Anyone have any information on how to develop TPM software?
 http://tpm4java.datenzone.de/
Using this lib, you need less than 10 lines of java-code for doing some
simple tpm operations.


Interesting, but not what I meant.  I want to program the chip to verify
that the BIOS, boot sector, root partition conform to *my* specification.

I don't want binary-only hardware-enforced vendor lock-in, that went
out of fashion
with the mainframe and proprietary data[base] formats.
--
TH

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-06 Thread Erik Tews
Am Donnerstag, den 05.10.2006, 16:25 -0500 schrieb Travis H.:
 On 10/2/06, Erik Tews [EMAIL PROTECTED] wrote:
  Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.:
   Anyone have any information on how to develop TPM software?
   http://tpm4java.datenzone.de/
  Using this lib, you need less than 10 lines of java-code for doing some
  simple tpm operations.
 
 Interesting, but not what I meant.  I want to program the chip to verify
 that the BIOS, boot sector, root partition conform to *my* specification.
 
 I don't want binary-only hardware-enforced vendor lock-in, that went
 out of fashion
 with the mainframe and proprietary data[base] formats.

You can do that (at least in theory).

First, you need a system with tpm. I assume you are running linux. Then
you boot your linux-kernel and an initrd using the trusted grub
bootloader. Your bios will report the checksum of trusted grub to the
tpm before giving control to your grub bootloader. Your grub bootloader
will then report the checksum of your kernel and your initrd to the tpm
before giving control to them.

After your kernel has bootet and given control to your initrd, you can
checksum your root-partition (or do something similar, like just
checking if there are setuid binarys or checksum just your shadow-file)
and report that to the tpm using a little java-application and tpm4java.

Later, you can remotely query your system and get a report what has been
bootet on your system. You can do this query using a java application
and tpm4java.

All applications like linux, grub, tpm4java are open source (you will
need a java-vm, there are some open source vms, you should be able to
use with tpm4java). The only thing which is not open source is the bios
and the exact hardware design of your tpm chip in your pc.

One thing you should know is, that a tpm can never find out, if a
software meets some specifications, like does not have an buffer
overflow or does not execute code from the network or so. You just can
check is has not been altered.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Re: TPM disk crypto

2006-10-06 Thread Travis H.

On 10/5/06, Erik Tews [EMAIL PROTECTED] wrote:

First, you need a system with tpm. I assume you are running linux. Then
you boot your linux-kernel and an initrd using the trusted grub
bootloader. Your bios will report the checksum of trusted grub to the
tpm before giving control to your grub bootloader. Your grub bootloader
will then report the checksum of your kernel and your initrd to the tpm
before giving control to them.


Awesome, that's incredibly useful information.
I had not heard of trusted grub.  Thanks!


One thing you should know is, that a tpm can never find out, if a
software meets some specifications, like does not have an buffer
overflow or does not execute code from the network or so. You just can
check is has not been altered.


Of course.  However, you can sandbox x86 code efficiently:
http://www.usenix.org/events/sec06/tech/mccamant/mccamant_html/index.html
--
Enhance your calm, fellow citizen; it's just ones and zeroes.
Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: TPM disk crypto

2006-10-02 Thread Erik Tews
Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.:
 Anyone have any information on how to develop TPM software?

Yes, thats easy. We created a java library for the tpm chip. You can get
it at 

 http://tpm4java.datenzone.de/

Using this lib, you need less than 10 lines of java-code for doing some
simple tpm operations.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil