An attack on paypal --> secure UI for browsers

[Joseph Ashwood]

----- Original Message ----- 
From: "Nomen Nescio" <nobody at dizum.com>
Subject:  Re: An attack on paypal --> secure UI for browsers


> Joe Ashwood writes:
> > From: "Anonymous" <nobody_at_cryptofortress.com>
> > > You clearly know virtually nothing about Palladium.
>
> > I still stand by, "Arbitrarily trusting anyone to write a secure program
> > simply doesn't work" regardless of how many times MS says "trust us" any
> > substantially educated person should as well be prepared to either trust
a
> > preponderance of evidence, or perform their own examination, neither of
> > these options is available.
>
> Apparently you neglected to read
> http://www.microsoft.com/resources/ngscb/NGSCB_Overview.mspx, where
> Microsoft says (as they have repeated many times) "Customers and partners
> need reliable ways to ensure the quality of technology that addresses
> the critical needs met by NGSCB. That's why Microsoft will make available
> for public review the source code of the core piece of enabling software
> in NGSCB, called the 'nexus,' so it can be evaluated and validated by
> third parties for both security and privacy considerations."
>
> Therefore some educated person (obviously not you, at least not yet)
> will in fact be able to perform their own examination of the trusted part
> of the OS, since it will have its source code published for exactly this
> sort of review.

I think there was some substantial miscommunication here (probably my fault
for snipping too much). Even assuming that MS's implementation is perfect,
the NCAs (as suggested by anonymous) would be downloaded from a variety of
sources, assumedly without source code. These are at least as big of a
threat, as the ActiveX saga demonstrates. The problem with ActiveX was never
that the core technology was itself causing problems, the problem was that
the supplemental technologies (the signature verification, the sandboxing
when applicable, etc) were continually being attacked by rogue ActiveX
components (I would consider everything form Gator to be such an attck) that
did undesirable things. Since the can I buy a vowel technology once called
Palladium "protects" these NCAs the result is a new ActiveX-type saga, even
if MS gets everything perfect. Assuming general software rules where bugs
will be present, we're looking at something potentially worse.

> Microsoft's legacy software is all extremely complex.  Palladium is
> taking a different approach, aiming at simplicity and transparency.
> The Nexus, which is the micro-kernel for the trusted components (NCAs),
> will be published for review.

But what about everything outside of the micro-kernel? It's still
untrustable.

> The brilliance of Palladium is that the LHS can't touch the RHS,
> because of hardware protection.

If that were true, the Palladium would be useless. The LHS, MUST be able to
touch the RHS, otherwise the LHS would be a completely seperate system, with
no software to run on it, performing no computation, and simply taking up
board space and processor time. However, there is a connection, and no
person has any control over what is run in the the LHS. That is in itself
problematic, and leads to a perfect avenue for massive abuse of power. And
as we all know the ability to abuse power, quite quickly leads to the abuse
of power.

> At one stroke, the new trusted mode is
> insulated from bugs in the Windows OS, device drivers and applications.

Except for the fact that the buggy everything can contact it, and give it a
new NCA, that NCA can do as it pleases.

> It in effect allows the designers to start with a clean piece of paper
> and produce a simple micro-kernel (the Nexus) whose only job is to
> service the NCAs.  This is a manageable task and, in conjunction with
> public review, there is good reason to hope and expect that the Nexus
> will be secure.

If you look I never suggested that the nexus itself would necessarily be
insecure, I've said that the supporting technology (everything MS has not
agreed to release) is open to massive abuse, and that the likelihood that it
will have numerous insecurities found is very high.

> If so then NCAs will indeed run in a mode where they
> are protected from other software components (including other NCAs).

But what about the rogue NCA? the one that decides to consume all the
processor, store inordinate amounts of information, spy on the user,
provided of course by the "buggy" software that put it there.

> As far as the NCAs being "foolishly trusted", all they are trusted to
> do is to run without being molested.  That's not exactly giving them the
> keys to the kingdom.  And see above for the reasons why it is reasonable
> to believe that they can in fact be trusted to run with this degree
> of security.

I guess I missed where you mentioned NCA at all before this, in fact I went
back and did a text search, the only ways that you mentioned NCAs so far
were "The Nexus, which is the micro-kernel for the trusted components
(NCAs), will be published for review," "and the NCAs acting as the
applications" "whose only job is to service the NCAs, " some rant about
manifest (which is another avenue for attack, but does not present what you
believe, and this one I'm responding to.. All you've done is rant on about
how the nexus this and the nexus that, completely ignoring the fact that
most of the problems with any operating system are not in the kernel
(micro-kernels are relatively easy), the problems continue to stem from the
same source they had in ActiveX, everything around the core component, the
loading, the verification, the scheduling, the stopping them from doing as
they please. These you have not even made an effort to address. You have
ranted around and around, pretending that spouting all these worthless words
actually justify claiming that can I buy a vowel, and all the NCAs that will
be produced by every company, all the hackers, various individuals, etc can
all be trusted. To quote myself yet again "Arbitrarily trusting anyone to
write a secure program simply doesn't work" and that is exactly what is
being claimed about can I buy a vowel.

> In my proposal, each ecommerce site would have its own unique NCA with
> its own unique identity.  As anyone who has studied NGSCB (except you)
> knows, NCAs are protected from each other as well as from the rest of
> the system.  Therefore rogue or compromised sites would not be able to
> touch the information that was being held for other sites.  e-go1d.com
> would not be able to get at the information associated with e-gold.com.
> Your proposed attack does not work.

What proposed attack? I never stated that the information protected by can I
buy a vowel would be compromised, I claimed that it will almost certainly
have gaping security holes, and that it's design makes some very bad
decisions. If each website has it's own NCA, then each website is free to do
as they please on your computer (including read the still encrypted
information form others), "Arbitrarily trusting anyone to write a secure
program" is a bad idea.

> Your comments above make it clear that you are not at all acquainted
> with the material in those documents.  If you're going to pretend to
> be a security expert

(remember when you advocated ECB mode for the XML
> encryption effort?!!),

Actually yes I do, and I still believe that ECB mode has its advantages in
very specific targets, if you had bothered to actually read the statements I
have made you would understand that. The goal I had for the possibility of
adding ECB was not to provide a common resource, but to push the issue of
clarity, by pushing the issue of ECB even slightly, I succeeded in having
clarity added to the document, both the spec and the XML. If you would
actually care to debate whether or not ECB is a valid mode for inclusion in
a wide usage standard, I suggest first you take it up with NIST, they have
perhaps the oldest standard for it, once you succeed in that, I suggest that
you consider all the border cases, especially the ones where a single block
is encrypted (other modes double the size), random data being encrypted
(which is equivalent security to all other modes), and where a limited
subset of the possible block space is being used (especially useful when
there is an attack that requires a large volume of text pairs). In each of
these cases ECB is at least as secure as any other mode, and in the last it
can be argued that under some circumstances it may actually be more secure.
I remember very well my advocation of ECB for XML Enc, it appears once again
to be you that has faield to grasp realities of the situation.

you could do worse than spending a few hours
> studying these documents closely.  It's very likely that NGSCB will
> be a central technology for security in the next two to ten years or
> even longer.  This is undoubtedly an area where security consulting
> could be lucrative.  Sadly, even "experts" of your caliber can probably
> be very successful in this area.  But you'll have to do your homework.

Here you go assuming things that simply aren't true. I don't see can I buy a
vowel becoming the "central techonology" for anything for very long. We're
already seeing the X86 processor being replaced at the high end, and slowly
being displaced at the mid-range, can I buy a vowel only has a few years
before it will need to be completely replaced, and since it will take a few
years for it to be adopted it's almost certainly a dead-end technology.

Now the other assumption, you assume that I intend to do security
consulting, how mistaken you are. I am actually the CEO of Trust
Laboratories, and security consulting would almost certainly be a pay cut.
There is a chance that eventually you can make something of yourself "But
you'll have to do your homework"
                    Joe


Trust Laboratories
Changing Software Development
http://www.trustlaboratories.com