----- Original Message ----- From: "Nomen Nescio" <nobody@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