Slashdot Mirror

Which one will it be the first to procure the secured operating system?

IEEE BOSS

or

Coyote OS

My money is on Coyote.

IEEE Standards Associate, IEEE Information Assurance, IEEE Computer Society and IEEE Baseline Operating System Specification Working Group (BOSSWG) has initiated a call for definitions of a new operating systems intended to securely control nearly all aspect of the operating system (including root).

Kinda sounds like Common Criteria, doesn't it; hopefully better.

"Looks like someone bought the IEEE's support of TCPA / Palladium"?

I had exactly the same first thought as you, so I dug around and found a link to their first draft and started reading to find evidence.

Here's their first draft in PDF format (1.6 meg), RTF format (5.0 meg), and a ZIP (1.2 meg).

I haven't read the whole thing, it's 76 pages, but as far as I can tell it hasn't been subverted by TCPA / DRM / Palladium / NaGSCaB / Trusted Computing nonsense. It looks like legitimate security designed for the benefit of the owner of the computer and for the benefit of authorized users.

Right from page 1 and page 2 it clearly says that it is designed to provide security only against unauthorized users. It says the standard does not attempt to secure the computer against authorized users. I made a cursory scan of the contents and didn't find any TCPA type warning signs. Of course this is still a first draft and that can always change, but it would take a pretty signifigant overhaul to subvert it into a TCPA system.

For anyone not familiar with TCPA, it is "evil" because it is not designed to secure the machine for the benefit of the owner and authorized users. TCPA is specificly designed to secure the machine against the owner and authorized users. The TCPA specification requires that the owner of the machine and authorized users must be denied any access to their own keys. If TCPA gave owners access to their keys you would get every single claimed benefit, but it would be useless for DRM.

-

"Looks like someone bought the IEEE's support of TCPA / Palladium"?

I had exactly the same first thought as you, so I dug around and found a link to their first draft and started reading to find evidence.

Here's their first draft in PDF format (1.6 meg), RTF format (5.0 meg), and a ZIP (1.2 meg).

I haven't read the whole thing, it's 76 pages, but as far as I can tell it hasn't been subverted by TCPA / DRM / Palladium / NaGSCaB / Trusted Computing nonsense. It looks like legitimate security designed for the benefit of the owner of the computer and for the benefit of authorized users.

Right from page 1 and page 2 it clearly says that it is designed to provide security only against unauthorized users. It says the standard does not attempt to secure the computer against authorized users. I made a cursory scan of the contents and didn't find any TCPA type warning signs. Of course this is still a first draft and that can always change, but it would take a pretty signifigant overhaul to subvert it into a TCPA system.

For anyone not familiar with TCPA, it is "evil" because it is not designed to secure the machine for the benefit of the owner and authorized users. TCPA is specificly designed to secure the machine against the owner and authorized users. The TCPA specification requires that the owner of the machine and authorized users must be denied any access to their own keys. If TCPA gave owners access to their keys you would get every single claimed benefit, but it would be useless for DRM.

-

"Looks like someone bought the IEEE's support of TCPA / Palladium"?

I had exactly the same first thought as you, so I dug around and found a link to their first draft and started reading to find evidence.

Here's their first draft in PDF format (1.6 meg), RTF format (5.0 meg), and a ZIP (1.2 meg).

I haven't read the whole thing, it's 76 pages, but as far as I can tell it hasn't been subverted by TCPA / DRM / Palladium / NaGSCaB / Trusted Computing nonsense. It looks like legitimate security designed for the benefit of the owner of the computer and for the benefit of authorized users.

Right from page 1 and page 2 it clearly says that it is designed to provide security only against unauthorized users. It says the standard does not attempt to secure the computer against authorized users. I made a cursory scan of the contents and didn't find any TCPA type warning signs. Of course this is still a first draft and that can always change, but it would take a pretty signifigant overhaul to subvert it into a TCPA system.

For anyone not familiar with TCPA, it is "evil" because it is not designed to secure the machine for the benefit of the owner and authorized users. TCPA is specificly designed to secure the machine against the owner and authorized users. The TCPA specification requires that the owner of the machine and authorized users must be denied any access to their own keys. If TCPA gave owners access to their keys you would get every single claimed benefit, but it would be useless for DRM.

-

You have to trust something. That which is trusted has to operate in a way that if it were made to do the wrong things, it would do the wrong things. Trust is the belief that it is not going to the wrong things. That which is not trusted has to be operated in a way that restricts its ability to do wrong things. But you cannot operate everything in the restrictive way because you have to trust the very mechanisms of restriction itself. And that generally means the kernel of the operating system, and the most of the hardware, have to be trusted to do the right things.

But the biggest issue is how do you establish that trust? Are you going to personally inspect every line of source code, and understand what it does? Are you going to inspect the engineering of the CPU and associated hardware that can influence how the CPU operates? Because we generally cannot do this on things as complex as computers or software, we have to establish trust by some proxy. If we know someone, and trust them, who has done all that, then we might trust the system. But there really isn't likely to be very many people around who can do that, and perhaps none at all. So somehow we have aggregate that trust proxy, and conclude on the basis of some combination of information, that something is trustable. But this isn't genuine trust. We cannot be certain that something is truly trustworthy just because someone says it is, or that a combination of others say it is.

Ultimately, we have to accept, and learn to deal with, the fact that trust is imperfect. We have to trust not that something cannot do the wrong thing, but that it is highly unlikely to do the wrong thing, and have contingency plans to be able to deal with it doing the wrong thing, which includes knowing that it did the wrong thing (it might try to hide that fact from you). The level we have to use to establish that trust will thus depend on the real and potential costs of the contingency (such as cleaning up the mess it leaves behind, restoring data, etc).

In order to reduce your contingency costs, you have to establish a greater criteria of trust. But the trust has a cost as well (for example hiring several computer scientists to inspect and analyze the code, as well as performing background checks on them to make sure they have no other motives, and even this has costs). It's all a balancing act. And where the optimal balance is will depend on many factors. As your contingency costs increase (a military has very high contingency costs, as it could mean losing to an opponent), your level of trust establishment needs to increase as well.

A standard for security has to address the fact that trust is imperfect, and that different entities will have different contingency costs. So it has to be flexible over a wide range of optimal levels of trust. If it is too rigid, it cannot be universally adopted, and will end up not being in common use (though it might find a niche use in areas matching its trust metrics). Those who are developing such a standard will at the very least need to state up front what the goal is. Is this something they expect to be usable in both a military high command setting, and in a casual home user setting? Unfortunately, I see none of this in the base document at the BOSS working group site.

You have to trust something. That which is trusted has to operate in a way that if it were made to do the wrong things, it would do the wrong things. Trust is the belief that it is not going to the wrong things. That which is not trusted has to be operated in a way that restricts its ability to do wrong things. But you cannot operate everything in the restrictive way because you have to trust the very mechanisms of restriction itself. And that generally means the kernel of the operating system, and the most of the hardware, have to be trusted to do the right things.

But the biggest issue is how do you establish that trust? Are you going to personally inspect every line of source code, and understand what it does? Are you going to inspect the engineering of the CPU and associated hardware that can influence how the CPU operates? Because we generally cannot do this on things as complex as computers or software, we have to establish trust by some proxy. If we know someone, and trust them, who has done all that, then we might trust the system. But there really isn't likely to be very many people around who can do that, and perhaps none at all. So somehow we have aggregate that trust proxy, and conclude on the basis of some combination of information, that something is trustable. But this isn't genuine trust. We cannot be certain that something is truly trustworthy just because someone says it is, or that a combination of others say it is.

Ultimately, we have to accept, and learn to deal with, the fact that trust is imperfect. We have to trust not that something cannot do the wrong thing, but that it is highly unlikely to do the wrong thing, and have contingency plans to be able to deal with it doing the wrong thing, which includes knowing that it did the wrong thing (it might try to hide that fact from you). The level we have to use to establish that trust will thus depend on the real and potential costs of the contingency (such as cleaning up the mess it leaves behind, restoring data, etc).

In order to reduce your contingency costs, you have to establish a greater criteria of trust. But the trust has a cost as well (for example hiring several computer scientists to inspect and analyze the code, as well as performing background checks on them to make sure they have no other motives, and even this has costs). It's all a balancing act. And where the optimal balance is will depend on many factors. As your contingency costs increase (a military has very high contingency costs, as it could mean losing to an opponent), your level of trust establishment needs to increase as well.

A standard for security has to address the fact that trust is imperfect, and that different entities will have different contingency costs. So it has to be flexible over a wide range of optimal levels of trust. If it is too rigid, it cannot be universally adopted, and will end up not being in common use (though it might find a niche use in areas matching its trust metrics). Those who are developing such a standard will at the very least need to state up front what the goal is. Is this something they expect to be usable in both a military high command setting, and in a casual home user setting? Unfortunately, I see none of this in the base document at the BOSS working group site.

It's true that some flaws in the OS are inherently design-based. However, even if we make certain design requirements to be incorporated in the OS, it still doesn't guarantee that the OS is secure. I would think that it even can't minimize the number of OS breaches. It would even hamper the OS development in order to comply with their standards.

About the quote regarding the "minimum expectations of consumers for security and general reliability by establishing a floor for these characteristics". I don't think it would be possible the goal of "the least restrictive requirement while not relenting the control" is vague. Unless it provides rigid post- or pre-conditions of each method (in first order logic if necessary) and provide each formal specifications unambiguously, I would still see some leaks here and there. And, guess what? They put the requirement like UML standards: Way to vague. Congratulations.

For those of you who are curious, click here for the draft.