Re: Cryptogram: Palladium Only for DRM

[David Wagner]

Peter N. Biddle wrote:
>[...] You can still extract everything in Pd via a HW attack. [...]
>
>How is this BORE resistant? The Pd security model is BORE resistant for a
>unique secret protected by a unique key on a given machine. Your hack on
>your machine won't let you learn the secrets on my machine; to me that's
>BORE resistant.  [...]

Yes, but...

For me, BORE (Break Once Run Everywhere) depends on the application.
You can't analyze Palladium in isolation, without looking at the app,
too.  It doesn't make sense to say "Palladium isn't susceptible to BORE
attacks", if the applications themselves are subject to BORE attacks.

For example, if a record company builds an app that stores a MP3 of
the latest Britney Spears song in a Palladium vault, then this app
will be susceptible to BORE attacks.  Extracting that MP3 from any one
machine suffices to spread it around the world.  It won't comfort the
record company much to note that the attacker didn't learn the Palladium
crypto keys living on other machines; the damage has already been done.
Palladium doesn't make DRM resistant to BORE attacks.  It can't.

In short, there are some applications that Palladium can't make
BORE-resistant.  Some apps (e.g., DRM) are simply fundamentally fragile.

Maybe a more interesting question is: For which apps does Palladium
provide resistance against BORE attacks that is not available by other
means?

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

Re: Cryptogram: Palladium Only for DRM

[Peter N. Biddle]

Hi Nomen

I am sending to crypto only as I am not on any of the other aliases you sent
to. Feel free to fwd.

How about "hacked" instead of "broken"? Broken implies that a machine
doesn't work; hacked implies it has been changed somehow but that it still
works. Let's say that a hacked Pd machine is a machine whose root keys have
been discovered through any means outside of the security model for that
machine. So a machine designed to give up its keys or to take keys in from
an outisde source isn't hacked. A machine whose security model includes
protecting the keys from everything, but whose keys have become known, is a
hacked machine. I can certainly imagine situations where Pd will be on a
hacked machine and won't know it.

Once the machine has been hacked, a user (or process, or piece of SW, or
whatever) can unlock all secrets which use the local keys as root keys. So
the symmetric keys used to protect a given piece of data would be
compromised, and all data which uses the same symmetric key can now be
unlocked. Rather than having to hand someone data, you could hand them keys
(presuming they have the data already). The "less global" a secret, the less
vulnerable it is to key hand-offs, but if more than one existence of
something is protected by the same key, that key represents an easily
distributed attack.

Even in cases where a given piece of data is secured with a unique key or
keys, once you have hacked those keys (or more likely the root keys used to
gen those keys) you can decrypt the data itself.  If all data in the world
only existed in Pd virtual vaults and was encrypted using different unique
keys, the data itself is still it's own secret. You can still extract
everything in Pd via a HW attack. Now rather than hand off the keys, you
hand off the data.

How is this BORE resistant? The Pd security model is BORE resistant for a
unique secret protected by a unique key on a given machine. Your hack on
your machine won't let you learn the secrets on my machine; to me that's
BORE resistant. Any use of Pd to protect global secrets reduces the BORE
resistance for the information protected by those secrets.

Only the Pd nexus (sorry, new name for the nub, er I mean TOR, er I mean
secure kernel, ...) knows each applications secrets, and it protects those
secrets from everything else absolutely. The nexus won't analyze data and
decide if it should or shouldn't be there; no Pd DRL's. (A DRM scheme on top
of Pd could enforce DRL's for content within its own vault, of course, but
it can't cross the vault boundary to try to enforce a DRL in someone else's
vault.) The goal is to protect data for whomever is asking for protection,
and to keep that data secure for that application. (I must note that we are
basing our design on existing US law. Should the law change and require
different behaviors, or should other countries require different behaviors,
we will need to find a way to comply.)

Palladium systems won't seek out and destroy anything, either locally or
remotely. Additionally the nexus has no understanding of what "legitmate" or
"illicit" means, so Pd really couldn't do this if it wanted to (it doesn't).
Data will be protected by Pd (in memory; on disk). Only applications with
the right hash (or those named by the original hashee) can access any given
piece of data.

P

- Original Message -
From: "Nomen Nescio" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, September 18, 2002 5:10 PM
Subject: Re: Cryptogram: Palladium Only for DRM


> Peter Biddle writes:
> > Pd is designed to fail well - failures in SW design shouldn't result in
> > compromised secrets, and compromised secrets shouldn't result in a BORE
> > attack.
>
> Could you say something about the sense in which Palladium achieves
> BORE ("break once run everywhere") resistance?  It seems that although
> Palladium is supposed to be able to provide content security (among
> other things), a broken Palladium implementation would allow extracting
> the content from the "virtual vault" where it is kept sealed.  In that
> case the now-decrypted content can indeed run everywhere.
>
> This seems to present an inconsistency between the claimed strength of the
> system and the description of its security behavior.  This discrepancy
> may be why Palladium critics like Ross Anderson charge that Microsoft
> intends to implement "document revocation lists" which would let Palladium
> systems seek out and destroy illicitly shared documents and even programs.
>
> Some have claimed that Microsoft is tal

Re: Cryptogram: Palladium Only for DRM

[José Azevedo]

People just keep piling up reasons to justify the SW suicide this is taking.

Perry is very right when he explains that a company that payed a certain
number of licenses has the right to deal with them in a manner that they
could be used in the purpose they were bought to. If a company spends a few
thousand dollars on hardware and software, it has every right to use that
software in a way that reachs it's purpose in the quantity that it was
licensed too. However, it is condemnable that a company can make use of 100
when they licensed 10, a model in wich many companies still incur.
But if someone tells me i have to pay an extra server license because i need
to install that SW in a brand new system, in preparation to replace the
older one in a 24x7 enviroment, i can tell you that is not going to happen.
And do you know why? Because there are ALTERNATIVES!
That's why market is such a beautifull place. When some product becomes too
screwy with itself, someone puts out another, different, and sometimes the
difference is the key to success, not just the improvement. Sometimes it
just needs to be a little different.

In a world where there are plenty of alternatives, i don't give a damn for
M$ and their bull, just because the time i have to license every step i make
on a computer is the time i go for the alternatives. And my friends, we know
that there are alternatives. And if M$ is great it is because we make it
great, and we can make it smaller again, and we can even create other SW
monster, we have the power to.
M$ is not even the best solution around, it's probably the one that most
people know about. That can also change.

Licensing of SW is dying because someone can make people believe HW and SW
are the same thing, but they aren't and that is a fact. HW is supposed to
last and SW is supposed to work. So, a 1 on 1 licensing is something that
will never be apliable in a real world with real problems.
Well, unless a messiah comes that can break every stupid crack M$ has on
their products, then the world would be perfect. But there it is, this isn't
a perfect world after all.

By the way, godbless cardioreaders aren't M$, or else we would be paying for
every heartbeat when we are in the hospital.

Good work everybody,
JFA




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

Re: Cryptogram: Palladium Only for DRM

[Perry E. Metzger]

bear <[EMAIL PROTECTED]> writes:
> On Wed, 18 Sep 2002, Peter wrote:
> 
> >Hi Pete - I'm confused. Are you suggesting that I should enjoy these
> >freedoms on SW which I don't have legal rights to?
> 
> In emergencies, yes.

This brings to mind my youth, in which I worked for a wall street firm
in which we systematically cracked the copy protection and license
managers on SunOS software we were using. Was it to pirate the
software? No. We paid for every license. It was because the
manufacturers had neglected to consider that in a 24x7 environment
having a machine go down meant that we needed to bring the software up
on hosts other than the one originally licensed, and we didn't have
time to wait until Monday when everyone got back to their office and
give us a new key. A few small kernel patches allowed us to routinely
tell programs that the host id was whatever we wanted them to think it was.

I recently have heard tell from friends of similar systematic uses of
cracked Microsoft software at a number of places -- not because these
places pirate the software, but because they can't deal with the
constant failures that the increasingly belligerent M$ copy
restrictions bring. Customers need to get work done, and the copy
protections get in the way. XP is particularly egregious in this
regard, but some people are getting around this with cracking tools,
even though they pay for their software legitimately.

One wonders if better license enforcement might not be a good thing,
since it would doubtless finish off Microsoft by eliminating the
ability of their legitimate customers to evade their license
enforcement software, thus driving them to use open source products.


Perry

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

Re: Cryptogram: Palladium Only for DRM

[bear]

On Wed, 18 Sep 2002, Peter wrote:

>Hi Pete - I'm confused. Are you suggesting that I should enjoy these
>freedoms on SW which I don't have legal rights to?

In emergencies, yes.  Remember the people trying to deal with
and organize the WTC rescue efforts, whose software kept rebelling
because of inappropriately-enforced license issues?  Care to even
estimate the liability for lives lost due to that?  You want to
create a system where they'd have *NO* way to override copyright
in a real emergency, *NO* way to save lives?  No. That's cut and
dried, because Copyright is never an emergency.  Copyright infraction
never costs lives.

I for one don't give a flaming shit whether someone has the
"legal rights" to equipment he has to use in an emergency to
save lives.  When putting automatic enforcement in place
means that lives will be lost, it is a Bad Idea. A company
that did it might (and IMO should) be held liable in court.

Furthermore, if you think that Pd will only be used for legal
purposes by the software vendors and manufacturers who control
it, I strongly suggest you revise your trust model  I have
seen no indication anywhere that these people are any more
trustworthy than those whose actions you decry. The only
difference is that the scale of abuses which can be perpetrated
by them is staggeringly large compared to the minor abuse of
someone copying a song or running a program out of license.

Bear


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

Re: Cryptogram: Palladium Only for DRM

[Ed Gerck]

"Peter N. Biddle" wrote:

> Hey Ed - I think that we may be in agreement. Most of what you say below
> makes sense to me.

what you said also looks good

> I'd love to see your papers.

A recent summary is at  http://nma.com/papers/gerck_on_trust.pdf

Cheers,
Ed Gerck




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

Re: Cryptogram: Palladium Only for DRM

[Nomen Nescio]

Peter Biddle writes:
> Pd is designed to fail well - failures in SW design shouldn't result in
> compromised secrets, and compromised secrets shouldn't result in a BORE
> attack.

Could you say something about the sense in which Palladium achieves
BORE ("break once run everywhere") resistance?  It seems that although
Palladium is supposed to be able to provide content security (among
other things), a broken Palladium implementation would allow extracting
the content from the "virtual vault" where it is kept sealed.  In that
case the now-decrypted content can indeed run everywhere.

This seems to present an inconsistency between the claimed strength of the
system and the description of its security behavior.  This discrepancy
may be why Palladium critics like Ross Anderson charge that Microsoft
intends to implement "document revocation lists" which would let Palladium
systems seek out and destroy illicitly shared documents and even programs.

Some have claimed that Microsoft is talking out of both sides of its
mouth, promising the content industry that it will be protected against
BORE attacks, while assuring the security/privacy community that the
system is limited in its capabilities.  If you could clear up this
discrepancy that would be helpful.  Thanks...

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

Re: Cryptogram: Palladium Only for DRM

[Peter N. Biddle]

Hey Ed - I think that we may be in agreement. Most of what you say below
makes sense to me.

This is how I have been describing trust recently - including it so that you
will at least understand where I am coming from when I use the term (cribbed
directly from a recent slide deck).

I can't trust anything (a component, an entity, etc.) unless.
I know who/what it is, and that it's not an imposter
I know its state-it has been properly initialized
I know that it cannot be tampered with
I know that my communication with it is private and tamper-proof
These are four elements of trust
I still need to be able to verify (trust) that the component behaves
properly in an ongoing manner

Everyone has different perspectives on "trust," some even contextual
"Doctrine of Multiple Trustors": trust is multi-way, not two-way
It is up to each party to determine its own trust criteria, and to
use mechanisms (e.g., certification) to measure and assert those criteria
Anything / everything can be certified to be trusted by anyone /
anything
 Many "things" (HW or SW) will be certified by more than one entity
Each entity may be measuring different facets of trust

I'd love to see your papers.

P

- Original Message -
From: "Ed Gerck" <[EMAIL PROTECTED]>
To: "Peter" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, September 18, 2002 10:04 AM
Subject: Re: Cryptogram: Palladium Only for DRM


> Peter:
>
> The question of "what is trust" might fill this listserver for months.
> But, if we want to address some of the issues that Pd (and, to some
> extent, PKI) forces on us then we must be clear what we mean when
> we talk about  trust in a communication system -- what is a trusted
> certificate, a trusted computer? Trusted for what? What happens
> when I connect two computers that are trusted on matters of X --
> are they trusted together on matters of X, less or more? What do
> we mean by trustworthy?
>
> I can send you some of my papers on this but the conclusion I arrived
> is that in terms of a communication process, trust has nothing to do with
> feelings or emotions.
>
> Trust is qualified reliance on information, based on factors independent
of
> that information.
>
> In short, trust needs multiple, independent channels to be communicated.
> Trust cannot be induced by self-assertions -- like, "trust me!"  or "trust
Pd!"
> More precisely, "Trust is that which is essential to a communication
channel
> but cannot be transferred using that channel."  Please see the topic
"Trust Points"
> by myself in "Digital Certificates: Applied Internet Security" by Jalal
Feghhi,
> Jalil Feghhi and Peter Williams, Addison-Wesley, ISBN 0-20-130980-7, pages
> 194-195, 1998.
>
> That said, the option of being *able* to define your own signatures on
what
> you decide to trust does not preclude you from deciding to rely on someone
> else's signature.  BTW, this has been used for some time with a hardened
version
> of Netscape, where the browser does not use *any* root CA cert unless you
sign
> it first.
>
> Thanks for your nice  comment ;-)
>
> Ed Gerck
>
>
>
> Peter wrote:
>
> > I disagree with your first sentence (I believe that Pd must be
trustworthy
> > for *the user*), but I like much of the rest of the first paragraph.
> >
> > I am not sure what value my mother would find in defining her own
> > signatures. She doesn't know what they are, and would thus have no idea
on
> > who or what to trust without some help.
> >
> > What my mother might trust is some third party (for example she might
trust
> > Consumer's Union). We assumed we needed a structure which lets users
> > delegate trust to people who understand it and who are investing in
> > "branding" their take on the trustworthiness of a given "thing" (think
UL
> > label, Good Housekeepking Seal of Approval, etc.). I totally agree that
some
> > small segment of users will have an active interest in managing the
trust on
> > their machines directly (like, maybe, us) but any architecture that you
want
> > to be used by "normal" PC users needs to also let users delegate this
> > managment to others who can manage it for users (just like we might
decide
> > to use others to manage our retirement funds, defend us in a court of
law,
> > or operate on our kidneys).
> >
> > To delegate trust, you need to start out trusting something to do that
> > delegation. That's part of what Pd is addressing - Pd needs to be
> > trustworthy enough so that when a user sets policy (eg "don'

Re: Cryptogram: Palladium Only for DRM

[Pete Chown]

Peter wrote:

> Hi Pete - I'm confused. Are you suggesting that I should enjoy these
> freedoms on SW which I don't have legal rights to?

No.

> If not, then I don't see how any of these freedoms are affected by Pd.

Well, how about the freedom to modify the software.  You said that it 
might be possible for users to compile the software themselves.  This 
would allow them to audit the software's function.  It would not allow 
them to change it, because a modified version wouldn't be trusted by the 
network.

-- 
Pete


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

Re: Cryptogram: Palladium Only for DRM

[Peter]

> (And before you mention the current worm infecting Linux apache sites,
> that's also caused by bad design, not an problem that requires
> hardware to fix.)

and

> In any case, all of this is silly. Palladium is no more likely to be
> bugless than the OS. If you break it, why is that less damaging than
> breaking the OS?

Bruce Schneier has a great take on this - secure systems should fail well.
Pd is designed to fail well - failures in SW design shouldn't result in
compromised secrets, and compromised secrets shouldn't result in a BORE
attack. I've talked about the processes we are using to make sure that this
is true but for a start we are gen'ing headers from formal specs. The specs
are reviewed for architecture and security before spec changes are approved,
and only then can you get a new header. We are doing a formal proof on parts
of the design (those upon which the security model depends). This process
should keep the bugs we do get from jeopardizing the security model.

P



- Original Message -
From: "Perry E. Metzger" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, September 16, 2002 1:32 PM
Subject: Re: Cryptogram: Palladium Only for DRM


>
> AARG!Anonymous <[EMAIL PROTECTED]> writes:
> > One likely use of Pd for banking software would be to use the "secure
> > vault" to lock up account number and password information.  This would
> > ensure that no other software than the banking client could access this
> > data,
>
> That's what an MMU and file permissions are for. Palladium isn't
> needed for such a thing.
>
> > so that if you got a virus it would not be able to empty your
> > banking account.
>
> Why not simply design the OS so it is not a likely victim for viruses?
> This is a general security problem, not one special to banking
> operations. My own machine doesn't seem to get viruses -- but then
> again it doesn't run Windows. Funny, that.
>
> (And before you mention the current worm infecting Linux apache sites,
> that's also caused by bad design, not an problem that requires
> hardware to fix.)
>
> > And if the virus infected the banking client software
> > itself, that would change its hash which would keep it from being able
> > to access the data.
>
> There are patches to NetBSD that happily prevent a program that does
> not have a particular hash from executing, and similar code for
> several other OSes I've seen. We need no hardware to do this. On the
> other hand, who needs hash functions when an ordinary user can't alter
> the executable because he doesn't have permissions?
>
> I know this is a new concept to windows users -- I had to give my CFO
> admin privs on his XP box because Quickbooks refused to run otherwise
> -- but it is indeed possible to work on a machine where you don't have
> the right to write every file on the system.
>
> In any case, all of this is silly. Palladium is no more likely to be
> bugless than the OS. If you break it, why is that less damaging than
> breaking the OS?
>
> > Contrary to Niels Ferguson's comments, these kinds of applications
> > are far from silly.
>
> I disagree. This is all like saying you need a rifle to shoot
> cockroaches when swatting them with a shoe does fine and using poison
> traps works even better. Using a rifle for the application is indeed
> silly.
>
> > The next Nimda could empty your bank account and transfer its entire
> > contents irreversibly to an overseas server.
>
> Not under US law it couldn't. You could just have the transfer
> reversed as fraudulent.
>
> Beyond that, though, there is the little detail that Nimda and Klez
> etc. are only possible because Windows is so poorly designed. I can't
> GET an email virus, because my machine doesn't have those sorts of
> design flaws. (It has plenty of others, but email viruses aren't a
> problem for me.)
>
> No, it appears to me that the only real excuse for Palladium is to
> allow third parties to take control of hardware I own to prevent me
> from using it the way that I want to. I don't need it to keep my bank
> account safe.
>
> --
> Perry E. Metzger [EMAIL PROTECTED]
> --
> "Ask not what your country can force other people to do for you..."
>
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
[EMAIL PROTECTED]
>

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

Re: Cryptogram: Palladium Only for DRM

[Peter]

Hi Pete - I'm confused. Are you suggesting that I should enjoy these
freedoms on SW which I don't have legal rights to?

If not, then I don't see how any of these freedoms are affected by Pd. If
you are suggesting that *all* SW should be made free, well that has nothing
to do with Pd, does it?

P

- Original Message -
From: "Pete Chown" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 17, 2002 4:16 AM
Subject: Re: Cryptogram: Palladium Only for DRM


> AARG!Anonymous wrote:
>
> > In addition, I have argued that trusted computing in general will work
> > very well with open source software.  It may even be possible to allow
> > the user to build the executable himself using a standard compilation
> > environment.
>
> This says it all.  "It may even be possible for you to keep a small
> subset of the freedoms you enjoy today."
>
> Have you seen Richard Stallman's introduction to free software?  I'd be
> interested to know what you think of each of the "freedoms" and whether
> you think they are available under Palladium/TCPA:
>
> http://www.gnu.org/philosophy/free-sw.html
>
> (Some of the freedoms are unaffected, of course.)
>
> --
> Pete
>
>
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
[EMAIL PROTECTED]
>

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

Re: Cryptogram: Palladium Only for DRM

[Peter]

> Your last comment is still valid though: Palladium etc. will
> be more compelling if it demonstrably preserved the control
> by the owner of a device (e.g., by allowing the owner to initialize the
> root keys used by it, as pointed out by
> William Arbaugh).

There is nothing in Pd which assumes that the keys weren't put there by a
crazy hobbit named Mel who waves a magic wand on every system and then
tattoos the keys on the users chest. Pd doesn't really know how the keys got
there (how would it?). Pd wants a HW cert which it can show to others, who
can then go to the signing authority for that cert and decide for themselves
whether or not they trust that HW. Note that "others" can represent SW,
remote users, local users, whatever...

Some organizations will certainly want to gen their own keys. Some users
will want to do this as well. The cost / benefit anaylsis involved in the
way the keys got into the machine, how they are managed, and how they are
preserved is up to a given market segment (where each segment happens to
consist of thousands or millions of users).

I believe that the chips in most Pd PC's will offer some relatively low bar
for HW tamper resistance, will self-gen keys, and will manage those keys
such that no one gets to know the private key and only third parties named
by the user will ever see the public key. I think that this serves the
widest set of needs. There may also be chips which squirt the keys out based
on some event and there will almost certainly be ones which take keys
squirted in from a remote source. Pd will run.

Think about the graphics business - one vendor sells a decent percentage of
silicon but there are other vendors who have been very succesful building
products which sell into different segments based on different feature sets,
and the same should hold true here. It is up to the makers of chips and
users to decide how they want to assert the trustworthiness of a given
system, and it is up to application writers to decide how they want to
operate on that machine based on the certs they are given by Pd.

re: smart cards - I agree, as a user I want the added protections I will get
from a combination of a smart card and biometrics on top of Pd. I ultimately
also want a mechanism I can use to ask an anonymous machine if I can trust
it, and a combined smart-card / bioemtirc device doing an authentication
with a Pd machine should let me do that.

P


- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 17, 2002 10:54 AM
Subject: Re: Cryptogram: Palladium Only for DRM


> David Wagner wrote:
> > I wasn't thinking of pure software solutions.  I was thinking of a
> > combination of existing hardware + new software: use the MMU to provide
> > separate address spaces, and use a secure VM or OS kernel to limit what
> > those processes can do.  As far as I can see, this can provide just as
> > much protection against viruses for your bank account as Palladium can.
>
> I agree with this in general.  One exception that comes
> to mind is "theft protection". If my machine has some
> secrets (e.g., to access my bank account) and a thief
> gets hold of the device physically (so that he can access
> the storage directly without the control of the OS), then MMU+software
> isn't enough. It seems some sort of smartcard
> (or support from a server) would be needed.
>
> The same applies to any data on my machine that should be
> integrity-protected (e.g., the root key with which
> I authenticate my bank).
>
> > In general, with software and existing hardware working together, I
> > suspect we can already do everything Palladium can do, except for the
DRM
> > and related applications founded on taking control away from the owner
> > of the machine.  Maybe I'm missing something.  Still, it seems to me
that
> > Palladium would much more compelling if it left out the tamper-resistant
> > chip and gave up on the semi-coercive DRM-like applications.
>
> I think tamper-resistant hardware could (if it worked)
> offer protection to the owner of the machine against anyone
> else who would have physical access to the machine. In other words,
> "Owner" is not the same as the "current user".
>
> Your last comment is still valid though: Palladium etc. will
> be more compelling if it demonstrably preserved the control
> by the owner of a device (e.g., by allowing the owner to initialize the
> root keys used by it, as pointed out by
> William Arbaugh).
>
> Regards,
> - Asokan
>
>
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
[EMAIL PROTECTED]
>

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

Re: Cryptogram: Palladium Only for DRM

[Ed Gerck]

Peter:

The question of "what is trust" might fill this listserver for months.
But, if we want to address some of the issues that Pd (and, to some
extent, PKI) forces on us then we must be clear what we mean when
we talk about  trust in a communication system -- what is a trusted
certificate, a trusted computer? Trusted for what? What happens
when I connect two computers that are trusted on matters of X --
are they trusted together on matters of X, less or more? What do
we mean by trustworthy?

I can send you some of my papers on this but the conclusion I arrived
is that in terms of a communication process, trust has nothing to do with
feelings or emotions.

Trust is qualified reliance on information, based on factors independent of
that information.

In short, trust needs multiple, independent channels to be communicated.
Trust cannot be induced by self-assertions -- like, "trust me!"  or "trust Pd!"
More precisely, "Trust is that which is essential to a communication channel
but cannot be transferred using that channel."  Please see the topic “Trust Points”
by myself in “Digital Certificates: Applied Internet Security” by Jalal Feghhi,
Jalil Feghhi and Peter Williams, Addison-Wesley, ISBN 0-20-130980-7, pages
194-195, 1998.

That said, the option of being *able* to define your own signatures on what
you decide to trust does not preclude you from deciding to rely on someone
else's signature.  BTW, this has been used for some time with a hardened version
of Netscape, where the browser does not use *any* root CA cert unless you sign
it first.

Thanks for your nice  comment ;-)

Ed Gerck



Peter wrote:

> I disagree with your first sentence (I believe that Pd must be trustworthy
> for *the user*), but I like much of the rest of the first paragraph.
>
> I am not sure what value my mother would find in defining her own
> signatures. She doesn't know what they are, and would thus have no idea on
> who or what to trust without some help.
>
> What my mother might trust is some third party (for example she might trust
> Consumer's Union). We assumed we needed a structure which lets users
> delegate trust to people who understand it and who are investing in
> "branding" their take on the trustworthiness of a given "thing" (think UL
> label, Good Housekeepking Seal of Approval, etc.). I totally agree that some
> small segment of users will have an active interest in managing the trust on
> their machines directly (like, maybe, us) but any architecture that you want
> to be used by "normal" PC users needs to also let users delegate this
> managment to others who can manage it for users (just like we might decide
> to use others to manage our retirement funds, defend us in a court of law,
> or operate on our kidneys).
>
> To delegate trust, you need to start out trusting something to do that
> delegation. That's part of what Pd is addressing - Pd needs to be
> trustworthy enough so that when a user sets policy (eg "don't run any SW in
> Pd which isn't signed by the EFF" or "don't run any SW which isn't
> debuggable"), it is enforced.
>
> P
>
> - Original Message -
> From: "Ed Gerck" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, September 17, 2002 2:51 PM
> Subject: Re: Cryptogram: Palladium Only for DRM
>
> >
> > It may be useful to start off with the observation that Palladium will not
> be
> > the answer for a platform that *the user* can trust.  However, Palladium
> > should raise awareness on the issue of what a user can trust, and what
> not.
> > Since a controling element has to lie outside the controled system, the
> solution
> > for a trustworthy system is indeed an independent module with processing
> > capability -- but which module the user should be able to control..
> >
> > This may be a good, timely opening for a solution  in terms of a "write
> code"
> > approach, where an open source trustworthy (as opposed to trusted)
> > secure execution module TSEM (e.g., based on a JVM with permission
> > and access management) could be developed and -- possibly -- burned on a
> > chip set for a low cost system. The TSEM would require user-defined
> > signatures to define what is trustworthy to *the user*, which would set a
> higher
> > bar for security when compared with someone else defining what is
> > trustworthy to the user.  The TSEM could be made tamper-evident, too.
> >
> > Note: This would not be in competition with NCipher's SEE, because
> NCipher's
> > product is for the high-end market and involves commercial warranties,
> > but NCipher's SEE module is IMO a good example.
> >
> > Comments?
> >
> > Ed Gerck
> >
> >
> >
> >
> > -
> > The Cryptography Mailing List
> > Unsubscribe by sending "unsubscribe cryptography" to
> [EMAIL PROTECTED]
> >


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

Re: Cryptogram: Palladium Only for DRM

[Peter]

I disagree with your first sentence (I believe that Pd must be trustworthy
for *the user*), but I like much of the rest of the first paragraph.

I am not sure what value my mother would find in defining her own
signatures. She doesn't know what they are, and would thus have no idea on
who or what to trust without some help.

What my mother might trust is some third party (for example she might trust
Consumer's Union). We assumed we needed a structure which lets users
delegate trust to people who understand it and who are investing in
"branding" their take on the trustworthiness of a given "thing" (think UL
label, Good Housekeepking Seal of Approval, etc.). I totally agree that some
small segment of users will have an active interest in managing the trust on
their machines directly (like, maybe, us) but any architecture that you want
to be used by "normal" PC users needs to also let users delegate this
managment to others who can manage it for users (just like we might decide
to use others to manage our retirement funds, defend us in a court of law,
or operate on our kidneys).

To delegate trust, you need to start out trusting something to do that
delegation. That's part of what Pd is addressing - Pd needs to be
trustworthy enough so that when a user sets policy (eg "don't run any SW in
Pd which isn't signed by the EFF" or "don't run any SW which isn't
debuggable"), it is enforced.

P

- Original Message -
From: "Ed Gerck" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, September 17, 2002 2:51 PM
Subject: Re: Cryptogram: Palladium Only for DRM


>
> It may be useful to start off with the observation that Palladium will not
be
> the answer for a platform that *the user* can trust.  However, Palladium
> should raise awareness on the issue of what a user can trust, and what
not.
> Since a controling element has to lie outside the controled system, the
solution
> for a trustworthy system is indeed an independent module with processing
> capability -- but which module the user should be able to control..
>
> This may be a good, timely opening for a solution  in terms of a "write
code"
> approach, where an open source trustworthy (as opposed to trusted)
> secure execution module TSEM (e.g., based on a JVM with permission
> and access management) could be developed and -- possibly -- burned on a
> chip set for a low cost system. The TSEM would require user-defined
> signatures to define what is trustworthy to *the user*, which would set a
higher
> bar for security when compared with someone else defining what is
> trustworthy to the user.  The TSEM could be made tamper-evident, too.
>
> Note: This would not be in competition with NCipher's SEE, because
NCipher's
> product is for the high-end market and involves commercial warranties,
> but NCipher's SEE module is IMO a good example.
>
> Comments?
>
> Ed Gerck
>
>
>
>
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
[EMAIL PROTECTED]
>

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

Re: but _is_ the pentium securely virtualizable? (Re: Cryptogram: Palladium Only for DRM)

[Peter]

The issue isn't whether or not the architeture as it existed in the past is
or isn't able to securely isolate user and kernel mode processes in an OS
which may not exist. If an OS can be written to securely isolate user and
kernel mode processes then I am sure that someone clever will find a way to
use it to do such a thing and may have an excellent security solution for
that OS which runs on current chips. I wish whomever tries to do this the
best of luck.

[Moderator's Obnoxious Note: I believe such an operating system is
called "Unix"...]

In Windows there are a number of reasons we can't use the current isolation
model for absolute enforcement of isolation. The biggest business reasons
are backwards compatibility for applications and kernel mode drivers, both
of which count on the current architecture and all of it's strengths (and
quirks). As we have stated before, we designed Pd with the assumption that
we couldn't break apps and we couldn't break device drivers.

Arbitrary Windows code which runs today must continue to run and function in
Pd as it does today, and yet Pd must still be able to provde protection.
Someone with a niche OS who doesn't care about breaking things may use a
different approach - they don't have gazllions of lines of 3rd party code
counting on version to version compatibility. We do.

>From a technical perspective, there are also a number of reasons that the
current isolation models don't work My guess is that a hard core Linux or
Unix kernel dev could probably explain this just as well as MS could,
however I will see if I can get someone on our end to outline the issues as
we see them.

I think that you are talking about separating user-mode processes in VMWare
(right?). What about SCSI controllers? The BIOS? Option ROMS? Kernel mode
device drivers? DMA devices? Random kernel foo.sys? What if the attack uses
SMM to attack VMWare itself? How does VMWare prove that the environment it
inherited when it booted is valid?

Lastly - Pd is only partially about process isolation. Nothing in the
current architecture even attmempts to address SW attestation, delegated
evaluation, authentication, or the sealing of data.

P


- Original Message -
From: "Nathaniel Daw" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Cypherpunks" <[EMAIL PROTECTED]>
Sent: Tuesday, September 17, 2002 3:01 PM
Subject: Re: but _is_ the pentium securely virtualizable? (Re: Cryptogram:
Palladium Only for DRM)


>
> > The fact that VMWare works just means they used some tricks to make it
> > practically virtualize some common OSes, not that it is no longer
> > possible to write malicious software to run as user or privileged
> > level inside the guest OS and have it escape the virtualization.
>
> I spoke with someone who had evaluated the appropriateness of the VMWare
> internals for security sandboxing with respect to just this point. He
> seemed to believe that it is simply not possible for processes in the
> guest to escape the sandbox (perhaps, in light of the paper you
> cite, this signals inefficiencies in VMWare). Other people on this list
> were, I believe, involved in porting VMWare to be hosted under the BSD
> architecture and may be able to speak further about this. In any case,
> the broader point that has been made repeatedly is that even if the
> Pentium is not efficiently, securely virtualizable due to quirks in its
> instruction set, clearly there are architectures which are but which avoid
> the objectionable, user-hostile, aspects of the Pd scheme.
>
> n
>
>
>
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
[EMAIL PROTECTED]
>

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

Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]

[Adam Shostack]

On Tue, Sep 17, 2002 at 01:07:43PM -0700, [EMAIL PROTECTED] wrote:
| >Now, lets say you don't tell the customer with known bad
| >software to go away, because you value their business.  Are you now
| >culpable in some way?  After all, you *knew* that client was
| >comprimised...
| 
| As far as I know, banks assume that a certain percentage of their 
| transactions will be bad and build that cost into their business 
| model.  Credit and ATM cards and numbers are as far from secure as 
| could be, far less secure than somebody doing online transactions 
| from a Wintel machine on an unencrypted connection, let alone an 
| encrypted one.  Until somebody takes full advantage of the current 
| system and steals a few trillion dollars in one day, the problems are 
| easier to deal with than a solution.  Until that happens, there's no 
| reason for banks to go through the pain of dealing with or requiring 
| Pd.

And after that happens, and the Fed declares a roll-back of a day,
there still won't be a reason.

Here's a fun thought experiment:  How much money could you steal and
launder before you cause a catastophic melt-down of the financial
privacy system, a la the way civil liberties have been set aside in
the wake of 9/11?


Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
   -Hume



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

Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]

[R. A. Hettinga]

At 1:07 PM -0700 on 9/17/02, [EMAIL PROTECTED] wrote:


> As far as I know, banks assume that a certain percentage of their
> transactions will be bad and build that cost into their business
> model.  Credit and ATM cards and numbers are as far from secure as
> could be, far less secure than somebody doing online transactions
> from a Wintel machine on an unencrypted connection, let alone an
> encrypted one.  Until somebody takes full advantage of the current
> system and steals a few trillion dollars in one day, the problems
> are  easier to deal with than a solution.  Until that happens,
> there's no  reason for banks to go through the pain of dealing with
> or requiring  Pd.

I wouldn't go that far. While Pd. -- and a certain long-term
ejaculative (look it up...) denizen of my kill-file -- is pretty much
a disingenuous shuck, greed is an amazing thing. The lowest cost
producer of anything, transactions, say, will not only make more
money than its competitors, but they will also *survive* longer than
anyone else. To quote, um, Stalin, "quantity has a quality all its
own."


So, if strong financial cryptography gives us the lowest
*risk-adjusted* cost per transaction by some very large amount, the
market will adopt it just as quickly as if confronted with a threat
that only strong cryptography can remedy.

As software (in the 
Gary Becker sense, things that can be more or less perfectly copied)
and wetware (valuable opinion, for lack of a better word) become more
important compared to hardware (stuff, discovered, extracted, or
built), the more valuable strong, secure, (geodesic :-)) networks and
(bearer :-)) financial cryptography becomes.



Cheers,
RAH




-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

RE: Cryptogram: Palladium Only for DRM

[Lucky Green]

AARG! Wrote:
> In addition, I have argued that trusted computing in general 
> will work very well with open source software.  It may even 
> be possible to allow the user to build the executable himself 
> using a standard compilation environment.

What AARG! is failing to mention is that Microsoft holds that Palladium,
and in particular Trusted Operating Root ("nub") implementations, are
subject to Microsoft's DRM-OS patent. Absent a patent license from
Microsoft, any individual developer, open source software development
effort, and indeed any potential competitor of Microsoft that wishes to
create a Palladium-like TOR would do so in violation of Microsoft's
patent. U.S. Patent law takes a dim view of such illegal infringers:
willful infringers, in particular infringers that generate a profit from
their creation of a non-Microsoft version of a TOR face the risk of a
court ordering such infringers to pay treble damages.

Palladium team representatives have indicated that Microsoft, or at
least the Palladium team, believes that Microsoft may license their
patented technology to competing efforts at some undecided time in the
future under terms that have yet to be contemplated, have so far not
been discussed with Microsoft's legal staff, and may or may not involve
remuneration.

As of this moment, Microsoft has not provided the open source community
with a world-wide, royalty-free, irrevocable patent license to the
totality of Microsoft's patents utilized in Palladium's TOR. Since open
source efforts therefore remain legally prohibited from creating
non-Microsoft TORs, AARG!'s lauding of synergies between Palladium and
open source software development appears premature.

> [1] A message from Microsoft's Peter Biddle on 5 Aug 2002; 
> unfortunately the cryptography archive is missing this day's 
> messages.  "The memory isn't encrypted, nor are the apps nor 
> the TOR when they are on the hard drive. Encrypting the apps 
> wouldn't make them more secure, so they aren't encrypted."  
> See also 
> http://www.mail-archive.com/cryptography@wasabisystems.com/msg
> 02554.html,
> Lucky Green's description of Microsoft's lack of plans to use Pd for
copy protection.

In the interest of clarity, it probably should be mentioned that any
claims Microsoft may make stating that Microsoft will not encrypt their
software or software components when used with Palladium of course only
applies to Microsoft and not to the countless other software vendors
creating applications for the Windows platform.

Lastly, since I have seen this error in a number of articles, it seems
worth mentioning that Microsoft stated explicitly that increasing the
security of DRM schemes protecting digital entertainment content, but
not executable code, formed the impetus to the Palladium effort.

--Lucky Green


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

Re: Cryptogram: Palladium Only for DRM

[Anne & Lynn Wheeler]

At 06:02 AM 9/17/2002 +, David Wagner wrote:
>I wasn't thinking of pure software solutions.  I was thinking of a
>combination of existing hardware + new software: use the MMU to provide
>separate address spaces, and use a secure VM or OS kernel to limit what
>those processes can do.  As far as I can see, this can provide just as
>much protection against viruses for your bank account as Palladium can.
>
>In general, with software and existing hardware working together, I
>suspect we can already do everything Palladium can do, except for the DRM
>and related applications founded on taking control away from the owner
>of the machine.  Maybe I'm missing something.  Still, it seems to me that
>Palladium would much more compelling if it left out the tamper-resistant
>chip and gave up on the semi-coercive DRM-like applications.


couple refs to multics study
http://www.garlic.com/~lynn/2002m.html#8 Backdoor in AES ?
http://www.garlic.com/~lynn/2002m.html#10 Backdoor in AES ?


--
Anne & Lynn Wheeler  [EMAIL PROTECTED],  http://www.garlic.com/~lynn/ 


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

Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]

[Anne & Lynn Wheeler]

At 01:07 PM 9/17/2002 -0700, [EMAIL PROTECTED] wrote:
>As far as I know, banks assume that a certain percentage of their 
>transactions will be bad and build that cost into their business 
>model.  Credit and ATM cards and numbers are as far from secure as could 
>be, far less secure than somebody doing online transactions from a Wintel 
>machine on an unencrypted connection, let alone an encrypted one.  Until 
>somebody takes full advantage of the current system and steals a few 
>trillion dollars in one day, the problems are easier to deal with than a 
>solution.  Until that happens, there's no reason for banks to go through 
>the pain of dealing with or requiring Pd.
>
>-Jon Simon

note that EU finread standard attempted to address some of this. an 
external (secure, finread) token acceptor device with secure display and 
secure pin entry. The hardware token is used to "sign" the (financial) 
transaction  PIN code is entered into the finread device and goes 
directly to the hardware token (w/o passing thru the PC). Critical pieces 
of the transactions passes thru the finread device on the way to the 
(signing hardware token) and is displayed on the secure display ... which 
then requires the PIN to be entered to confirm the transaction.

There is the issue of 3-factor authentication

* something you have (hardware token)
* something you know (pin)
* something you are (biometrics in addition to &/or in place of PIN)

besides the straight-forward use of signatures to authenticate the source 
of the transaction ... there is the nominal legal requirement associated 
with physical signatures ... i.e. did you intend to sign what you signed 
aka is what you "see" what you signed ... and do you confirm that you 
actually want the hardware token to sign what you "see".

A lot of digital signature seems to address the technology part of 
authentication ... and then sometimes (just because the term "signature" is 
used as part of the description of the technical procedure) that all 
technical implementations of the process referred to as "digital signature" 
is legally equivalent to "physical signatures" (even when no aspects of 
intention have been satisfied).

random past finread & intention posts:
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, 
here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative 
to PKI?
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, 
or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during 
ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/2000.html#0 2000 = millennium?
http://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history...
http://www.garlic.com/~lynn/2000f.html#79 Cryptogram Newsletter is off the 
wall?
http://www.garlic.com/~lynn/2001f.html#39 Ancient computer humor - DEC WARS
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#51 future of e-commerce
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001j.html#46 Big black helicopters
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral 
infection?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001n.html#70 CM-5 Thinking Machines, 
Supercomputers
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security 
requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security 
requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet 
Banking
http://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet 
Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#13 Biometric authentication for 
intranet websites?
http://www.garlic.com/~lynn/

Re: Cryptogram: Palladium Only for DRM

[Ed Gerck]

It may be useful to start off with the observation that Palladium will not be
the answer for a platform that *the user* can trust.  However, Palladium
should raise awareness on the issue of what a user can trust, and what not.
Since a controling element has to lie outside the controled system, the solution
for a trustworthy system is indeed an independent module with processing
capability -- but which module the user should be able to control..

This may be a good, timely opening for a solution  in terms of a "write code"
approach, where an open source trustworthy (as opposed to trusted)
secure execution module TSEM (e.g., based on a JVM with permission
and access management) could be developed and -- possibly -- burned on a
chip set for a low cost system. The TSEM would require user-defined
signatures to define what is trustworthy to *the user*, which would set a higher
bar for security when compared with someone else defining what is
trustworthy to the user.  The TSEM could be made tamper-evident, too.

Note: This would not be in competition with NCipher's SEE, because NCipher's
product is for the high-end market and involves commercial warranties,
but NCipher's SEE module is IMO a good example.

Comments?

Ed Gerck




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

but _is_ the pentium securely virtualizable? (Re: Cryptogram: Palladium Only for DRM)

[Adam Back]

On Mon, Sep 16, 2002 at 11:01:06PM -0400, Perry E. Metzger wrote:
> [...] in a correctly operating OS, MMUs+file permissions do more or
> less stop processes from seeing each others data if the OS functions
> correctly.

The OS can stop user processes inspecting each others address space.
Therefor a remote exploit in one piece of application software should
not result in a compromise of another piece of software.  (So an IE
bug should not allow the banking application to be broken.)  (Note
also that in practice with must current OSes converting gaining root
once given access to local processes is not that well guaranteed).

However the OS itself is a complex piece of software, and frequently
remote exploits are found in it and/or the device drivers it runs.  OS
exploits can freely ignore the protection between user applications,
reading your banking keys.

Even if a relatively secure OS is run (like some of the BSD variants),
the protection is not _that_ secure.  Vulnerabilities are found
periodically (albeit mostly by the OS developers rather than
externally -- as far as we know).  Plus also the user may be tricked
into running trojaned device drivers.

So one approach to improve this situation (protect the user from the
risks of trojaned device drivers and too large and complex to
realistically assure security of OSes) one could run the OS itself in
ring0 and a key store and TOR in ring-1 (the palladium approach). 

Some seem to be arguing that you don't need a ring-1.  But if you read
the paper Peter provided a reference for, they conclude that the
pentium architecture is not (efficiently) securely virtualizable.  The
problem area is the existance of sensitive but unprivileged
instructions.

The fact that VMWare works just means they used some tricks to make it
practically virtualize some common OSes, not that it is no longer
possible to write malicious software to run as user or privileged
level inside the guest OS and have it escape the virtualization.

(It is potentially inefficently securely virtualizable using complete
software emulation, but this is highly inefficient).

(Anonymous can continue on cypherpunks if Perry chooses to censor his
further comments.)

Adam
--
http://www.cypherspace.net/

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

RE: Cryptogram: Palladium Only for DRM

[Trei, Peter]

> Niels Ferguson[SMTP:[EMAIL PROTECTED]] wrote:
> 
> Well, I'm tired of this. AARG, or whoever is hiding behind this pseudonym,
> is obviously not reading the responses that I send, as he keeps asking
> questions I already answered. I'm not going to waste more of my time
> responding to this. This is my last post in this thread.
> 
> Have Fun!
> 
> Niels
> 
Of course, this is just what AARG wants - he has never actually been
interested in trying to persuade you. He just wants to wear down the
people who are able to effectively dispute his claims to the point
where they shut up, abandon the field of battle, and leave his position
trimphant by default. 

He doesn't care about the truth, or whether you have shown him to
be false. He just wants to win. 

Peter Trei




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

Re: Cryptogram: Palladium Only for DRM

[asokan]

David Wagner wrote:
> I wasn't thinking of pure software solutions.  I was thinking of a
> combination of existing hardware + new software: use the MMU to provide
> separate address spaces, and use a secure VM or OS kernel to limit what
> those processes can do.  As far as I can see, this can provide just as
> much protection against viruses for your bank account as Palladium can.

I agree with this in general.  One exception that comes
to mind is "theft protection". If my machine has some
secrets (e.g., to access my bank account) and a thief
gets hold of the device physically (so that he can access
the storage directly without the control of the OS), then MMU+software 
isn't enough. It seems some sort of smartcard
(or support from a server) would be needed.

The same applies to any data on my machine that should be
integrity-protected (e.g., the root key with which
I authenticate my bank).

> In general, with software and existing hardware working together, I
> suspect we can already do everything Palladium can do, except for the DRM
> and related applications founded on taking control away from the owner
> of the machine.  Maybe I'm missing something.  Still, it seems to me that
> Palladium would much more compelling if it left out the tamper-resistant
> chip and gave up on the semi-coercive DRM-like applications.

I think tamper-resistant hardware could (if it worked)
offer protection to the owner of the machine against anyone
else who would have physical access to the machine. In other words, 
"Owner" is not the same as the "current user".

Your last comment is still valid though: Palladium etc. will
be more compelling if it demonstrably preserved the control
by the owner of a device (e.g., by allowing the owner to initialize the 
root keys used by it, as pointed out by
William Arbaugh).

Regards,
- Asokan


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

Re: Cryptogram: Palladium Only for DRM

[Bill Frantz]

At 11:02 PM -0700 9/16/02, David Wagner wrote:
>AARG!Anonymous  wrote:
>>David Wagner writes:
>>> Standard process separation, sandboxes, jails, virtual machines, or other
>>> forms of restricted execution environments would suffice to solve this
>>> problem.
>>
>>Nothing done purely in software will be as effective as what can be done
>>when you have secure hardware as the foundation.
>
>I wasn't thinking of pure software solutions.  I was thinking of a
>combination of existing hardware + new software: use the MMU to provide
>separate address spaces, and use a secure VM or OS kernel to limit what
>those processes can do.  As far as I can see, this can provide just as
>much protection against viruses for your bank account as Palladium can.

The KeyKOS work  shows an approach to
using existing hardware protection (in the case of KeyKOS, the protection
available in the IBM 370 hardware) to building a system that is very
resistant to Trojan horses and Virii.  A very closely related open source
OS is Eros .

Use of these technologies is illustrated by "A Security Analysis of the
Combex DarpaBrowser Architecure" by David Wagner & Dean Tribble
 and a presentation
at the O'Reilly Emerging Technology Conference, "The E Development
Platform: Exploiting Virus-Ridden Software"
.

Cheers - Bil


-
Bill Frantz   | The principal effect of| Periwinkle -- Consulting
(408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave.
[EMAIL PROTECTED] | fair use.  | Los Gatos, CA 95032, USA



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

Re: Cryptogram: Palladium Only for DRM

[sasKuach]

9/16/2002 7:47:27 PM, AARG!Anonymous <[EMAIL PROTECTED]> wrote:

>Running an open-source program on a trusted computing platform provides
>the best of both worlds.  The user is protected against misbehavior
>on the part of the executable, because he knows exactly what it can do.
>And the software is protected against misbehavior on the part of the user,
>by virtue of the hardware protection.  In this way, the interests of all
>parties are balanced.

And what exactly is misbehavior on the part of the user? The user owns the
computer and should be able to do whatever he so disires with it.


-
See why TCPA and Palladium
are only good for Microsoft
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html



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

Re: Cryptogram: Palladium Only for DRM

[Niels Ferguson]

Well, I'm tired of this. AARG, or whoever is hiding behind this pseudonym,
is obviously not reading the responses that I send, as he keeps asking
questions I already answered. I'm not going to waste more of my time
responding to this. This is my last post in this thread.

Have Fun!

Niels

At 00:00 17/09/02 -0700, AARG! Anonymous wrote:
>Niels Ferguson writes:
>
>> Like I said before, most of the Pd stuff is really welcome. Everything
>> except the secure chip is a great improvement, and long overdue. My
>> observation is that the secure chip is only needed to do DRM, and that
>> trying to sell it to the public under the 'we need more security' banner is
>> bogus.
>
>I will respond more tomorrow, but just to clarify: you can't think of
>any situation in the banking example where it would be useful for the
>server to have confidence that the client is running legitimate software?
>This would add no security to any form of distributed banking software?
>
>And more generally, you can't think of any application, other than DRM,
>where it would be useful for a server to have some assurance that a
>remote system was running a particular piece of software?  Nothing at all?
>
>It's funny how people have different blind spots.  Microsoft supposedly
>can't think of any way to use Pd for DRM and yet Lucky Green comes up
>with several methods without even trying.  Turn the tables, and the
>greatest cryptographic minds in the field can't come up with good uses
>for secure attestation, but an ordinary guy like me comes up with a
>handful while walking the dog.
>
>
==
Niels Ferguson, [EMAIL PROTECTED], phone: +31 20 463 0977
PGP: 3EC2 3304 9B6E 27D9  72E7 E545 C1E0 5D7E

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

Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]

[Adam Shostack]

On Mon, Sep 16, 2002 at 09:57:13PM -0500, Ted Lemon wrote:
| >Relevence to the Pd debate is that banks may in future insist on remote
| >attestation of users' software (however practically possible that is) 
| >so
| >that they can attempt to dump yet more liability on their users 
| >("Ladies and
| >gentlemen of the jury, Mr Doe's claim that he did not authorise this
| >transfer to a Caribbean account is obviously fraudulent as his Fritz 
| >chip
| >proved to us that his system had not been compromised"...)
| 
| Banks typically aren't that sophisticated.   Demand for this capability 
| probably will not materialize in time to save Pd, although there are 
| probably people working for banks who will claim that they want it.

As soon as you start doing this, it becomes clear what a nightmare it
is for the bank to try to learn anything about its customers.

Firstly, its customers are diverse, and the breadth of information you
get is large.  Second, what you learn falls into three categories
"known good," "unknown," and "known bad."  Smart security people want
to say what is not explicitly ok is bad.  That means most of your
customers have bad software, and lots of it.  Do you deny them access?
Ask that they upgrade?  Are you responsible if their upgrade breaks
things?  Now, lets say you don't tell the customer with known bad
software to go away, because you value their business.  Are you now
culpable in some way?  After all, you *knew* that client was
comprimised...

PS: Hi Ashish! :)


-- 
"It is seldom that liberty of any kind is lost all at once."
   -Hume



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

Re: Cryptogram: Palladium Only for DRM

[Niels Ferguson]

At 16:00 17/09/02 +1200, Peter Gutmann wrote:
>>But I am not suggesting to do it purely in software. Read the Intel manuals
>>for their CPUs. There are loads of CPU features for process separation,
>>securing the operating system, etc. The hardware is all there!
>
>There was a rather nice paper at Usenix Security 2000 on this [pause]
>available from
>http://www.usenix.org/publications/library/proceedings/sec2000/robin.html

Thanks, Peter, for a nice reference. That paper points out that the Pentium
doesn't make it easy to create a virtual machine that is perfectly
transparent, i.e. that the OS inside the VM cannot detect the VM at all. I
don't think that is the current concern, as the OS and secure kernel are
being developed by the same company. I'm sure the secure kernel is
significantly easier to develop if you can make some small changes to the
OS code, but even without this VMware shows that it can be done without any
help of the OS.

Niels
==
Niels Ferguson, [EMAIL PROTECTED], phone: +31 20 463 0977
PGP: 3EC2 3304 9B6E 27D9  72E7 E545 C1E0 5D7E

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

Re: Cryptogram: Palladium Only for DRM

[Pete Chown]

AARG!Anonymous wrote:

> In addition, I have argued that trusted computing in general will work
> very well with open source software.  It may even be possible to allow
> the user to build the executable himself using a standard compilation
> environment.

This says it all.  "It may even be possible for you to keep a small 
subset of the freedoms you enjoy today."

Have you seen Richard Stallman's introduction to free software?  I'd be 
interested to know what you think of each of the "freedoms" and whether 
you think they are available under Palladium/TCPA:

http://www.gnu.org/philosophy/free-sw.html

(Some of the freedoms are unaffected, of course.)

-- 
Pete


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

Re: Cryptogram: Palladium Only for DRM

[David Wagner]

AARG!Anonymous  wrote:
>David Wagner writes:
>> Standard process separation, sandboxes, jails, virtual machines, or other
>> forms of restricted execution environments would suffice to solve this
>> problem.
>
>Nothing done purely in software will be as effective as what can be done
>when you have secure hardware as the foundation.

I wasn't thinking of pure software solutions.  I was thinking of a
combination of existing hardware + new software: use the MMU to provide
separate address spaces, and use a secure VM or OS kernel to limit what
those processes can do.  As far as I can see, this can provide just as
much protection against viruses for your bank account as Palladium can.

In general, with software and existing hardware working together, I
suspect we can already do everything Palladium can do, except for the DRM
and related applications founded on taking control away from the owner
of the machine.  Maybe I'm missing something.  Still, it seems to me that
Palladium would much more compelling if it left out the tamper-resistant
chip and gave up on the semi-coercive DRM-like applications.

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

Re: Cryptogram: Palladium Only for DRM

[Peter Gutmann]

Niels Ferguson <[EMAIL PROTECTED]> writes:
>At 16:04 16/09/02 -0700, AARG! Anonymous wrote:
>>Nothing done purely in software will be as effective as what can be done
>>when you have secure hardware as the foundation.  I discuss this in more
>>detail below.
>
>But I am not suggesting to do it purely in software. Read the Intel manuals
>for their CPUs. There are loads of CPU features for process separation,
>securing the operating system, etc. The hardware is all there!

There was a rather nice paper at Usenix Security 2000 on this [pause]
available from
http://www.usenix.org/publications/library/proceedings/sec2000/robin.html

Peter.

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

Re: Cryptogram: Palladium Only for DRM

[Perry E. Metzger]

It takes a lot for me to get cranky around here, but I'm afraid Aarg!
has done it.

AARG!Anonymous <[EMAIL PROTECTED]> writes:
> Perry Metzger writes:
> > Why not simply design the OS so it is not a likely victim for viruses?
> > This is a general security problem, not one special to banking
> > operations.
> 
> That's a great idea.  I don't know why nobody thought of that before.

You conveniently cut what I said selectively, sarcastically replying
to only pieces of it. You completely ignored much of the substance,
such as the fact that in a correctly operating OS, MMUs+file
permissions do more or less stop processes from seeing each others
data if the OS functions correctly.

So, to summarize, you ignored most of what I said, but managed to be
incredibly rude. I've noticed you doing the same to lots of others.

Here's a strong suggestion for the future, Anonymous. Never anger the
moderator of a moderated mailing list. You can be the agent
provocateur all day long, but you can't be snide and unresponsive.

I'm going to ask that you go back and respond to my message without
being insulting and without being selective about what sections you
quote. If you want another copy, well, I don't know how to send it to
you -- I can only hope you saved it. Until then, I'm not forwarding
your mail.

If you want to play your game here, you're going to have to do it
politely and reasonably. Sorry for doing this in public but I have no
other way of communicating with you.


Perry

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

Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]

[Ted Lemon]

> Relevence to the Pd debate is that banks may in future insist on remote
> attestation of users' software (however practically possible that is) 
> so
> that they can attempt to dump yet more liability on their users 
> ("Ladies and
> gentlemen of the jury, Mr Doe's claim that he did not authorise this
> transfer to a Caribbean account is obviously fraudulent as his Fritz 
> chip
> proved to us that his system had not been compromised"...)

Banks typically aren't that sophisticated.   Demand for this capability 
probably will not materialize in time to save Pd, although there are 
probably people working for banks who will claim that they want it.


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