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.
The information available does not cover the technical information, in fact their "Technical FAQ" about it actually has the following:
"Q: Does this technology require an online connection to be used?
A: No. "
That is just sooooo enlightening, and is about as far from a useful answer as possible.
Very few of the Technical FAQ answers are so brief. In this case, it is a stupid question and deserves a trivial answer. The only reason it is in there is because of the lies spread by Lucky Green and Ross Anderson, all about how Palladium will connect to a central server and refuse to let you work with your own documents, or delete files that Microsoft or the U.S. Government don't like.
NCAs do not have "complete access to private information". Quite the opposite. Rather, NCAs have the power to protect private information such that no other software on the machine can access it. They do so by using the Palladium software and hardware to encrypt the private data. The encryption is done in such a way that it is "sealed" to the particular NCA, and no other software is allowed to use the Palladium crypto hardware to decrypt it.
This applies only under the condition that the software in Palladium is perfectly secure. Again I point to the issues with ActiveX, where a wide variety of hoels have been found, I point to the newest MS operating system which has it even been out a month yet? and already has a security patch available, in spite of their "secure by default" process. Again I don't believe this is because MS is inherently bad, it is because writing secure programs is extremely difficult, MS just has the most feature bloat so they have the most problems.
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. Its tasks are relatively few and well defined, nothing like the massive Windows OS. That is what Microsoft has gained by architecting Palladium as they did, with the new "trusted" CPU mode, which allows side-by-side operating systems to run. On the left hand side (LHS) we find the legacy Windows OS and applications. On the right hand side (RHS) we find the Nexus acting as the OS, and the NCAs acting as the applications. The brilliance of Palladium is that the LHS can't touch the RHS, because of hardware protection. At one stroke, the new trusted mode is insulated from bugs in the Windows OS, device drivers and applications. 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 so then NCAs will indeed run in a mode where they are protected from other software components (including other NCAs).
If the Palladium software is actually secure (unlikely), then there is the issue of how the (foolishly trusted) NCAs are determined to be the same, this is an easy problem to solve if no one ever added features, but a hard one to solve where the program evolves, once MS shows the solution for this, I will point to the same information and show you a security hole.
Read the documents! Actually you claim you already read them, but obviously you are lying or you would know that this question has been answered. I wrote a long posting about this last month explaining how it worked. The mechanism is called a Manifest and is described in section 9 of http://www.microsoft.com/resources/ngscb/documents/ngscb_tcb.doc. You can either use a hash of the NCA (which would not allow the NCA to be updated) or you can use a signing key, where NCAs signed by the same key would effectively share the same identity. The Manifest can also limit which other components are used by the NCA. It's a very flexible system. 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.
In the proposed usage, an NCA associated with an ecommerce site would seal the data which is used by the user to authenticate to the remote site.
After running unattended on your computer, a <sarcasm>brilliant</sarcasm> idea, hasn't anyone learned?
The authentication data doesn't actually have to be a certificate with associated key, but that would be one possibility. Only NCAs signed by that ecommerce site's key would be able to unseal and access the user's authentication credentials. This prevents rogue software from stealing them and impersonating the user.
Not in the slightest, a single compromise of a single ecommerce site (remember they're "trusted") will remove all this pretend security. Let's use a particularly popular example on here right now www.e-go1d.com, they could easily apply to be an ecommerce site, they collect money, they offer a service, clearly they are an ecommerce site. Are you really gullible enough to believe that they won't do everything in their power to exploit the data transfer problem above, as well as any other holes in Palladium? I should hope not.
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.
Seriously, have you read any of the documents linked from http://www.microsoft.com/resources/ngscb/?
Yes I have, in fact at this point I think it is safe to say that you have not, or you didn't understand the implications of the small amount of information it actually contains.
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?!!), 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.
On Fri, 13 Jun 2003, Nomen Nescio wrote:
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."
So why isn't it open for review *before* it's finalized? Might it give too many people an idea of what's really wrong with it?
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.
Let's see it now. Not after it's finisihed.
Microsoft's legacy software is all extremely complex. Palladium is taking a different approach, aiming at simplicity and transparency.
I want the drugs you are on dude. You have a very rosy picture, and it seems all your inputs have been hijacked by supreme chemicals!
The Nexus, which is the micro-kernel for the trusted components (NCAs), will be published for review. Its tasks are relatively few and well defined, nothing like the massive Windows OS. That is what Microsoft has gained by architecting Palladium as they did, with the new "trusted" CPU mode, which allows side-by-side operating systems to run. On the left hand side (LHS) we find the legacy Windows OS and applications. On the right hand side (RHS) we find the Nexus acting as the OS, and the NCAs acting as the applications.
And in the mean time the user can't control their own computer.
The brilliance of Palladium is that the LHS can't touch the RHS, because of hardware protection. At one stroke, the new trusted mode is insulated from bugs in the Windows OS, device drivers and applications. 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 so then NCAs will indeed run in a mode where they are protected from other software components (including other NCAs).
Very nice drug induced rant. Too bad reality doesn't work that way. Who owns the hardware? The user or the RIAA? True hardware protection means the user is protected from Microsoft, not the other way around.
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?!!), 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.
Palladium changed to NGSCB and will morph to something else and something after that. It won't ever fly because the user can't control their own machine. Trust is a two way street. Until Microsoft learns to trust their customers, nobody will trust Microsoft. What we do in person we can do on a computer. We can con each other in person, so we'll be able to con each other with computers. That's how reality works, and no hardware or laws is going to change that. Instead of trying to wave a magic wand while everyone is on lsd, it'd be better if Microsoft and the RIAA came out with their own hardware for the specific purpose of DRM sales. Everyone would know who owns the hardware because they'd just rent it instead of buying it. IBM is already on the right track for this. Microsoft has yet to get it. Patience, persistence, truth, Dr. mike
The faq (see attached) claims that "anyone can write a nexus" and that "users control which nexus(s) run". I certainly didn't see anything that suggests that anyone can force you to run arbitrary code, regardless of who has signed it. I also find it absurd to worry about what code Microsoft is running on your system. If you are running their operating system, you are already running arbitrary code from them. If you install a security or functional patch, you are running arbitrary code from them. How would this be different? My only real concern is that once this becomes widespread, having the correct "nexus" + DRM software installed will be the only way to get play digital media. I have a feeling I won't be playing any of that content from the MythTv box in my living room... AdamL -- http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/... Q: What is the "nexus" component of NGSCB? A: The nexus is a new Windows OS component that will be introduced as part of NGSCB. The nexus, what we used to refer to as a "nub" or "trusted operating root," is essentially the kernel of an isolated software stack that runs alongside the existing software stack. The nexus provides a limited set of APIs and services for applications, including sealed storage and attestation functions. Think of nexus-aware applications as residing in the user mode space of the parallel execution environment and the nexus as residing in the kernel mode space. Anyone can write a nexus for use with nexus-aware systems. The user always has the ultimate authority over what nexuses are allowed to run. Only one nexus at a time will be able to run on a machine. Q: What is the privacy model associated with NGSCB? A: The user is always in control of whether or not nexus-aware technology is enabled on his or her PC and what nexuses have access to specific functions. The technology being developed as part of NGSCB provides a fine-grained access control model that allows users to specify (by hash) whether an individual nexus has the right to invoke a specific security operation. In addition, SSC functions that reveal potentially machine-identifying information, such as the RSA public key, can only be performed once per SSC reset (and the SSC cannot be reset from software; you have to power-cycle the PC). -- Adam Lydick <adam.lydick@verizon.net>
Adam Lydick wrote:
The faq (see attached) claims that "anyone can write a nexus" and that "users control which nexus(s) run".
I certainly didn't see anything that suggests that anyone can force you to run arbitrary code, regardless of who has signed it.
"Force", maybe not. No one can "force" me to turn my machine on, for instance. But take a look at one line you quoted from the FAQ: "Only one nexus at a time will be able to run on a machine." That looks to me like an important sentence.
That is certainly a good point but don't confuse the "nexus" with NCAs (agents). I think the nexus just provides services to the NCAs which actually do the work. Think of it as a core library that services can draw on. So having to trust the nexus, is rather like trusting kernel32.dll or some other core components. Choosing to trust/run NCA sounds pretty grainular, so you can trust your validated P2P stack from your favorite independent developer and ignore (if you can) the restrictive DRM solutions that are offered. Problems certainly remain though: In the validated P2P scenario, an Adversary with enough influence to have Intel/AMD/... hand out a signed internal key can circumvent any such "protections". Thoughts? AdamL On Sat, 2003-06-14 at 11:50, David Wagner wrote:
Adam Lydick wrote:
The faq (see attached) claims that "anyone can write a nexus" and that "users control which nexus(s) run".
I certainly didn't see anything that suggests that anyone can force you to run arbitrary code, regardless of who has signed it.
"Force", maybe not. No one can "force" me to turn my machine on, for instance. But take a look at one line you quoted from the FAQ:
"Only one nexus at a time will be able to run on a machine."
That looks to me like an important sentence. -- Adam Lydick <adam.lydick@verizon.net>
----- 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
participants (5)
-
Adam Lydick
-
daw@mozart.cs.berkeley.edu
-
Joseph Ashwood
-
Mike Rosing
-
Nomen Nescio