bluetooth cryptosystems

[Perry E. Metzger]

Does anyone have good pointers to papers on the security of E0 and the
rest of the stuff used in bluetooth? It all looks very fragile.

-- 
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]

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: but _is_ the pentium securely virtualizable? (Re: Cryptogram:Palladium Only for DRM)

[Nathaniel Daw]

> 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]

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: Interests of online banks and their users [was Re:Cryptogram: Palladium Only for DRM]

[jon]

>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.

-Jon Simon

-
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]

(FWD) 'LaGrandium' and the Dark Side of 'Trusted' Computing

[rsedc]

  http://www.eweek.com/article2/0,3959,528840,00.asp

  'LaGrandium' and the Dark Side of 'Trusted' Computing
  By  Jason Brook

  On Monday, Intel introduced its development forum attendees to LaGrande, a trusted
  computing technology slated for inclusion in future Intel processors, perhaps as 
soon as the
  middle of next year. 

  Intel's LaGrande-based processor chips (AMD plans to include similar features in its 
own
  chips) are supposed to team with a future Microsoft OS technology called Palladium to
  deliver a more controllable-and therefore more secure-computing platform than we have
  today.
 
  Now, whether these "trusted" platforms will result in more security and control
  for the individual computer user remains to be seen. 

  The trusted computing platform that Intel and Microsoft are countenancing
  would be built around a protected memory space in which trusted services run, a
  sealed storage mechanism for storing encrypted data, and a facility for providing
  operating environment information to outside parties.  In Microsoft's Palladium
  materials, those outside parties are called "external requestors."

  ...


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

NSP Security List

[R. A. Hettinga]

--- begin forwarded text


Status: RO
From: "Barry Raveendran Greene" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: NSP Security List
Date: Mon, 16 Sep 2002 19:46:32 -0700
Sender: [EMAIL PROTECTED]


Hello Everyone,

Thanks to Jared's sponsorship, we are creating a nsp-* mailing list for the
NSP Security Operations community. We will use the nsp-security for NSP
security coordination and consultation. We expect most of the consultation
to be on procedures, polices, tools, mitigation techniques, and other
proactive activities.  We will also try to use the list as an incident
response alias - tracking and mitigating attacks in progress.

Membership to the alias will be restricted to those actively mitigating of
NSP Security incidents.  Therefore, it will be limited to operators,
vendors, researchers, and FIRST team and other people in the NSP operations
community working to stop attacks.  That means no press and (hopefully) none
of the "bad guys." We will use a simple trust/peering relationship used on
some of the other aliases.  This model is not as "secure" as an encrypted
conversation, but better than a wide-open public dialog.  We will establish
the trust by asking members of the list to vouch for new subscriber
requests.  If the list administrators know the person, then they can vouch
for them.

Yes, we have had similar "security" lists in the past.  With nsp-security we
will connection the E-mail dialog with face-to-face meetings in the
operations conferences.  The first "meeting" is the ISP Security BOF at the
next NANOG.  Like NANOG's Peering BOF, the ISP Security BOF is a
facilitation tool ... bring together people living with the daily pain of
ISP Security incidents.  So the hope is the combination of face-to-face and
private E-mail list will help use take forward steps.

So apply for subscription, send a note to:

[EMAIL PROTECTED]

with the word "subscribe" in the subject or body of the message.
Alternatively, you can use the web page at:

http://puck.nether.net/mailman/listinfo/nsp-security


Barry

PS - Looking for a couple more volunteers to help as administrators.

~
Barry Raveendran Greene|   |||||
Senior Consultant  |   |||||
CTO Corporate Consulting   |       |
   |  ..:||:..:||:..   |
e-mail: [EMAIL PROTECTED]  |  C i s c o S y s t e m s  |
Phone: +1 408 525-8089
~

--- end forwarded text


-- 
-
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

[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]