Should Colleges Embrace or Fear Microsoft's New Security System?

I've been a member of the group for almost a year, primarily working on the "next-generation secure computing base," which we call NGSCB. I also participate in standardization of the XrML 2.X rights expression language in OASIS and other XML security standards in the World Wide Web Consortium. Before joining the trusted-platforms group, I was the development lead for the .NET Framework security system. I started at Microsoft back in the fall of 1997 as the program manager for core cryptography in Windows 2000.

I'm a cryptographer by training, although my doctoral thesis (MIT '96) was in the area of automated-resource discovery, which is the use of small-scale artificial intelligence in client tools to help find interesting resources on distributed information networks.

The topic for today’s discussion is Microsoft’s next-generation secure computing base -- NGSCB. This medium isn't the best for drawing diagrams, so I'll try to do my best to answer your question without resorting to ASCII art :-). Shall we take the first question?

How will Palladium affect the exchange of data between Palladium systems and non-Palladium systems, such as earlier Microsoft systems, or Pentium-based Linux systems, or non-Intel systems such as Macintosh computers?

A: First off, let's be clear that applications have to opt into using NGSCB technology in the first place. Today's applications will run just as they always have on an NGSCB-capable system, so there would be no possible impact on non-aware applications.

If an NGSCB-aware application chooses to use the new hardware to secure information while it's on disk, say, it's still up to the application, as always, as to what its export policies are for the data. In terms of data protection, NGSCB provides applications with better encryption technology for protecting data associated with the application, but the application always gets to choose how that data is protected and transferred to others.

Also, could someone build a non-Pentium-based Palladium trust system?

A: From a technical standpoint, certainly. The NGSCB architecture is designed to be processor- and memory-manager agnostic, although of course we depend on the presence of some hardware security features in both of those components. If someone wanted to build a NGSCB-class machine on top of a processor other than an x86, they'd need to add those features to the other processor and memory controller, but it's technically possible.

And finally, will Microsoft license for reasonable and normal fees any patents involved?

A: I can't really speak to what Microsoft's IP licensing policies will be around NGSCB, other than to say that it's something we realize is critical and it's something we are working on right now. As you can imagine, there are a lot of issues and considerations, but we understand that our ability to get this one right is critical to the overall success of the technology.

Is it possible that some publisher would choose to use NGSCB technology to enforce onerous controls on their content? Yes, that's certainly possible, and it's something I worry about personally, but the technology is ultimately agnostic. Seen another way, the technology could potentially also serve to reduce the security concerns of some publishers so that they'd make more data available electronically.

Ultimately, the policies governing content have to be the result of open negotiation and agreement between the content owner and consumer. It's essential, in my view, that everyone understands and agrees to those policies before they are put in place. (At the end of the day, the marketplace will decide.) NGSCB technology includes, as one of its features, a policy-neutral evaluation engine. This allows client machines (and, ultimately, the owner of the machine) to have greater control over the software and data running on their local machines. It also allows clients and server to mutually prove to each other that they "speak the same policy language" and agree to abide by the same rules.

Increasing the confidence between two parties that they behave as they expect, given that they have never met in the physical world, is something I believe can help make more information available than is today.

The problem is further exacerbated by the fact that copyright law in general is a liability-based system, whereas authorization systems in computer security are conditional access systems. I do believe that, with some of the sufficiently advanced policy languages now under development, it would be possible to encode some of the limitations on the exclusive rights of copyright holders that are present in U.S. Copyright law. For example, the exception in 17 USC 108 that grants libraries the right to make a certain number of archival copies seems possible, assuming that there was a trusted third party that could certify who is a "library" under the law. I think it will be possible for the community to make incremental improvements over time and to define larger and larger encodeable subsets of the limitation on exclusive rights in systems.

(Let me leave it there for now. I'm a co-author on a short paper that will appear in the April '03 Communications of the ACM that talks more about this possible approach.)

There's one additional component that needs to be added to PC motherboards, something we call the security-support component (SSC), which is a little bit of cryptographic hardware to store a few crypto keys and perform some basic crypto algorithms. We believe the SSC will cost only a few dollars, max, in large quantities, so the incremental cost to OEM will be small.

Look at the definition of any security protocol, and generally you'll find at the core a box labeled "TCB" with a big black border drawn around it. That's the critical component that has to work as expected for the protocol to actually be secure. So, no, NGSCB isn't a loss-leader. It's a fundamental improvement in the security architecture of the PC.

As for the second part of your question -- how will non-NGSCB platforms access NGSCB-protected content -- I've answered that previously. It all depends on what the policies of the application are that protected the content in the first place. NGSCB doesn't automatically protect any data. It provides services that can be used by applications to do so. So at the end of the day, it's up to the application -- just like it is today.

One of the core requirements of a TCB is that everyone involved understand exactly how it works and what it does. The TCB has to be open, transparent, and comprehensible. We recognized that requirement from the start, and to be quite honest, that's why Microsoft has started discussing NGSCB technology with academics so early in the design process. It's why I gave open seminars on NGSCB at MIT, Carnegie Mellon, and the University of Minnesota. There's another one coming up at Yale University next month. It's also why we've committed to publishing the source code to the NGSCB nexus -- the security kernel. And it's why I'm here participating in this Web chat.

In fact, I think it's a good thing because in order for TCBs to be deemed trustworthy, they have to be inspected and understood by lots of people. I think it's perfectly OK to hold our feet to the fire, so to speak, and to scrutinize every aspect of the architecture. At the end of the day I think that can only work to improve the overall security and acceptance of the NGSCB environment.

I do think there's a second thiing going on here, which is that the NGSCB architecture proposes some low-level changes to the PC hardware, which are pretty far away from the typical computer-security issues that colleges are dealing with right now. It's not like we're saying here'ss a better firewall technology that stops X from happening. That would be pretty easy to relate to and to understand the impact of.

The NGSCB architectural changes have the potential to improve many different aspects of distributed computing security, but it takes time for the higher-level applications to be designed and implemented on top of the new architecture. There's definitely going to be a "bubble-up" effect years down the road after NGSCB-capable systems are widely available. But that doesn's help university network administrators defend their systems today.

In the NGSCB architecture, a machine owner has to explicitly designate which nexuses are allowed to run in the NGSCB-protected environment. If a student or group of students wanted to write their own nexus with different APIs and a different security model for applications hosted on top of their nexus, that would certainly be possible. In fact, it would probably make a good end-of-term project in an upper-level undergrad operating systems course.

In terms of innovation, personally I believe that the presence of NGSCB-capable systems will stimulate more innovation among software developers. I'm sure we've only thought of a fraction of the possibilities for this security platform, and I certainly expect many new, interesting and innovative uses of that technology from students and other energetic software developers. As for your question about Mach and Windows, I can't really speak to that except to say that Microsoft, like all technology companies, is always interested in building strong relationships with the academic community.

Even assuming that the nexus is bug-free and that it cannot be affected by viruses or bugs in the rest of the Windows system, how can Palladium achieve its goals if a) the data provided to the nexus can't be trusted completely and b) if decisions that the nexus makes about granting access, for example, can't be trusted to be enforced reliably?

Brian A. LaMacchia:
    The nexus, like a traditional operating-system kernel, governs access to a set of resources and has to make decisions about what applications running on top of it have access to those resources. In addition to things like memory access and access to the interprocess communication (IPC) channel to the rest of the operating system, the nexus also governs access to the resources of the SSC.

So, for example, if a nexus computing agent, which is an NGSCB application, wants to generate a random cryptographic key pair and store it securely, the nexus provides the protection mechanism for that key pair.

More generally, one of the main functions of the nexus is to make sure that data that an application has asked to be protected is only returned in unprotected form to the application that saved it in the first place or to another application designated by the first application). When making trust decisions, the nexus policy evaluator has to make an independent determination of the trustworthiness of every security credential presented to it. In general, this means that the credentials need to be signed by some entity that the nexus trusts, or the nexus had to have issued those credentials in the first place.

Just as today security systems use a mix of self-issued credentials and credentials issued by trusted third parties, policies written for the nexus can do the same thing.

FYI, for those of you who will be at the RSA Security conference in April, I will be giving a presentation on NGSCB there -- Thursday morning, I think. Although I don't have the location yet, I will be presenting a seminar on NGSCB at Yale University Thursday, March 27.