In court yesterday Microsoft VP Jim Allchin defended the security exception to disclosure in the proposed Microsoft-DoJ settlement, which is derided by opponents as "security by obscurity," but under cross-examination by States' attorney Kevin Hodges he went some way toward defining the protocols and APIs that Microsoft would keep security under the banner of security.

The precise meaning of the clauses in the proposed settlement referred to here needn't detain us, but the protocols and APIs have some considerable relevance, because they'll help us assess how strong Microsoft's argument is. If the wider disclosure provisions of the States' proposals were implemented, Allchin argues that " the risks are greatly increased that valuable information stored on computers will be stolen and that computers will be subjected to malicious attacks."

So, how many protocols will be withheld? Allchin suggests just the one, and possibly only for a limited period:

A. It is possible that all protocols, barring one, will end up being disclosed underneath 3(e). But it's not done, the analysis isn't complete yet.
Q.[Hodges throughout] Can you tell me what the one protocol is that you currently believe may not be disclosed pursuant to section 3(e)?
A. Yes, I can. There is a protocol dealing with software functionality in Windows called message cueing [queueing], and there is a mistake in that protocol. And that mistake, if we disclosed it, would in my opinion, would compromise a company who is using that particular protocol. We are replacing that protocol. But today, I think if we disclosed it, it would be not the right thing to do for our customers. That's an example.

That's a classic example of security by obscurity. There's something bad in there, and if the hackers got hold of it all hell would break loose. Actually though, one begs leave to doubt this. If knowledge of the hole were such a big deal, should not the Microsoft attorneys have been hopping up and down shouting 'close the session,' and should not Jim, who is after all in charge of this stuff, have pleaded confidentiality? Presumably transcript-reading hackers will have the final say on this.

As regards APIs, Allchin said the analysis determining which ones would be withheld was still in progress, but came up with some examples:

A. There are things dealing with antipiracy and things dealing with digital rights management. For sure, they come to mind as I sit here.
Q. Are there particular names or ways of describing these APIs that you can use?
A. I don't remember the specifics right now. There is one dealing with Windows file protection -- or maybe it's two with Windows file protection. You know, I can't remember in terms of the DRM.

In his deposition earlier Allchin had given the Secure Audio Path component of its DRM system as an example of something that would not have been disclosed prior to the proposed settlement, but which would now. Clearly, though, there are other things it wants to hold onto, so could these roadblock Real et al? Allchin said that he didn't know the number of APIs that would be withheld, that he didn't expect there to be a very large number, but that "some of them are very important."

"As I said in my testimony, I think there's a confusion about authentication and the way keys are used in authentication and the ways that keys are used in digital rights when you're trying to protected content. It may come to you, but the content owner wants to not have that be sent to somebody else or not used in some way. And in those cases we have to hide keys and the algorithms for manipulating those in -- physically in the code, so that level of disclosure would compromise installations."

Hodges went on to explore this "confusion about authentication," and found some in the Microsoft camp. In his deposition Microsoft witness Roger Needham, managing director of Microsoft Research in Cambridge, had a narrower view of such matters:

Q. Mr. Allchin, if I could ask you to turn to page 45, starting at line 4. Let me read you the question and answer. "Question: Do you believe this RFPJ J-1 is necessary to protect anything other than keys and the locations of keys? "Answer: I don't believe it is. It is to protect keys and the locations of keys from being indirectly inferred." Do you see that testimony?
A. I do.
Q. Do you agree with that testimony by Professor Needham?
A. No. Unfortunately, I don't. It's partly right, but my example of a protocol with an error in it is a classic example of how I wouldn't agree with him on that.

So Needham is right provided everything works, but Allchin wishes to use security by obscurity as a backstop for when it doesn't, if we understand that correctly. The whole problem with the proposed settlement, of course, is that when it comes down to it, we don't believe them. Sure, if Microsoft confines itself to keeping real security issues close to its chest, that's one thing, but this company has a legal record, doesn't it, so it can't be trusted. Cut to the chase:

Q. All right. Mr. Allchin, what language, in section 3(j)1, would prevent Microsoft from using the security exception to withhold information, other than the mistake in protocol that you mentioned, the location of keys, and the cryptographic keys themselves?
A. I want to be as precise as I can be here. It's "would compromise," to me, that's the key, if you will, about us having the ability to use 3(j)1 versus the documentation requirements that we have for 3(d) and 3(e). And in your question I felt like you were trying to say: Okay, is this the absolute limit of what you might find? And I already said that we're not complete. I think through my testimony I've sort of said, you know, there are only a few places so far that I know of that this is going to end up to be applicable, but we haven't completed it, and I do feel quite strongly that I have to look after our customers. We have -- you know, we are trying to work on a reputation of security in the marketplace.

Or indeed, to establish one which we have not at this juncture got. Allchin undoubtedly does have a major and genuine job on his hands in getting a lid on Microsoft security issues, but the huge noise the Redmond marketing morlocks made about security becoming the number one priority earlier this year suggests that some people in the company are more concerned about the reputation than the nuts and bolts of reality. Hodges pursues more detail:

Q. You would agree that section 3(j)1 would allow Microsoft to withhold from disclosure information beyond cryptographic keys and the locations of cryptographic keys; correct?
A. I -- I would.
Q. If we could look at section 3(j)1, there's a list of several different types of information that would be withheld from disclosure. The first is antipiracy system. Do antipiracy systems in Windows expose cryptographic keys or the location of those keys?
A. I'm sorry. I don't understand the question. Do they expose? Do they use keys? Yes. I'm trying to answer. I don't understand.
Q. Well, the use of the key itself, would that require Microsoft to withhold from disclosure APIs and protocols associated with antipiracy systems?
A. In the narrow sense. You have to look at the specifics. We disclose a lot, as I mentioned in my testimony, about Windows file protection, but there's a part of the algorithm which we use that we have hidden, if you will, in the operating system because we don't want pirates to steal the system. So if we were required to disclose it under 3(d) or 3(e), then that part I would want to not have to be disclosed.
Q. Are you talking about disclosure of APIs now?
A. You could talk about it as either, but the most important part here that I was personally talking about was the APIs, yes.
Q. So is it your testimony that if you disclose the API, you're also disclosing the algorithm that pirates would need to make copies of Windows?
A. There are APIs that if we expose them, the more we say, as an example, if you hang your key outside your door and it's always there and you tell people that's where it is, it's not -- it's a risk. So, yes, there is at least one API that I can think of dealing with the Windows file protection that I don't want to disclose because it would make it easier for people to either do antivirus -- or attack us in a virus sense or antipirate, or pirate us.

One kind of hopes he meant something rather different from what he said just there about antivirus, but Hodges then presses him on Kerberos. After establishing that it's open, but that Microsoft has added proprietary extensions, they proceed as follows:

Q. Is Kerberos an authentication system?
A. Yes, it is. It's a protocol.
Q. So Kerberos is something that would fall under section 3(j)1; correct?
A. I don't know what "fall under" means. We've decided that we're going to not invoke 3(j)1 for any authentication coming out of the Windows operating system to a Windows operating system -- or Windows server.
Q. When did you make that decision?
A. I don't know. Within the last month, maybe.
Q. The SRPFJ, do you recall when this was negotiated?
A. The attorneys would be better at that. In the fall.
Q. So is it correct there was a period of time when Kerberos was subject to the nondisclosure provision of section 3(j)1; correct?
A. Well, we had until August of this year to make the pass through the protocols, according to the SRPFJ. And I haven't read all the testimony in this trial, but -- or hearing, but there are many, many protocols, and we have been methodically walking through each of them. So it's no big surprise at all to me to be where we are today.
Q. Am I correct that protocols are not disclosed until Microsoft decides, after analyzing them under section 3(j)1, that they should be disclosed?
A. Yes. We have to do that by August when this -- for the first deliverable of those protocols.
Q. So up until about a month ago the extension to Kerberos was not disclosed; correct?
A. That is correct.

Hodges then goes on to talk about the protocols and APIs Microsoft has already identified as not for disclosure, and asks if there is any necessity for the company to say which haven't been disclosed. No, says, Allchin, there is not, and "that would defeat the purpose of the 3(j)1. I don't want -- the fact that I even mention the message cueing [queuing] thing here bothers me."

Q. So when Microsoft decides that an API or protocol is not subject to disclosure in reliance of section 3(j)1, it simply doesn't disclose those APIs or protocols and also doesn't make an announcement that it has failed to disclose them; is that correct?

Indeed. So if your software doesn't work with Windows, you're going to have considerable difficulty figuring out whether it's your software that's broken, Microsoft's software that's broken, or whether it's something Microsoft isn't telling you. And Microsoft isn't going to tell you it's not telling you. Layered security by obscurity, and a familiar process.

There's plenty more of interest here, but we'll call it a day for now, leaving you with an excerpt that may shed light on some of the cracking XP exploits of last year:

Q. So it's possible for hackers to find unprotected undisclosed interfaces within Windows; correct?
A. Yes. It's a question of how hard we make it.
Q. Has that been done in the past?
A. If for a digital rights we had an attack where, because of a coding error, they discovered the algorithms for how the key was, and the code, was obfuscated for DRM.
Q. This is the data rights management mechanism in Windows XP; is that right?
A. Well, it didn't have to do with Windows XP per se, but it was the DRM functionality. By the time Windows XP was done that issue had been addressed to my knowledge.
Q. The DRM mechanism is something that is not published by Microsoft; is that correct?
A. That is correct, except in how you use it.
Q. Did the part that was not published, is it correct that someone figured that out and published details on the Internet?
A. Yes. They spent a great deal of time reverse engineering the technology. ®