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..."
---
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 someb
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 Microso
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
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
> 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
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, th
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
>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
> 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
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 prov
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 w
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
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:
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
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
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 possib
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
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
--- 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 t
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 pure
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
> >
> 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 authoris
23 matches
Mail list logo
