Mike Nash made a snide remark that "I should also note that in contrast to the existing AES implementations that have not been through an evaluation, we plan to get our implementation evaluated to meet FIPS guidelines and requirements." Might have been true when he said it, but it's no longer true. OpenSSL completed its FIPS 140-2 approval earlier this month. See http://www.linuxelectrons.com/article.php/20060122 164238268 for an article about it; the approval (certificate #626) should be posted at http://csrc.nist.gov/cryptval/140-1/1401val2006.ht m before too long.
The author of the Business Week article missed a key point. FIPS 140 is talking about encryption, not security. You can be FIPS 140 certified, and still have completely unpatched holes. All FIPS 140 tells you is that the crypto algorithms work correctly (including random number generation, etc).
Common Criteria, as others in this discussion have noted, is much more relevant. While it's not perfect (the vendor gets to pick the security features they want to claim, and they get to pick who does the approval), at least it requires a search for security vulnerabilities, and an effort to make sure that the product is architecturally sound.
Sounds to me like the people at InfoGard Labs sold Business Week on the article, and they didn't have anyone who understood what the certification is about.
I'm definitely not a Microsoft fan, but this is not true. SAIC was the organization that did the NT4 C2 evaluation, and they're in the process of doing a Win2K evaluation. See http://www.radium.ncsc.mil/tpep/epl/entries/TTAP-C SC-EPL-99-001.html for the NT evaluation, and http://niap.nist.gov/cc-scheme/InEvaluation.html for the Win2K ongoing effort.
Incidentally, it was NT 3.5 that was certified without networking... NT 4.0 included networking in their evaluation. See http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EP L-95-003.html
I don't know whether the x86 or RISC processors can support positive growth stacks. Haven't kept up on hardware architectures.
As for fighting code that assumes stack growth downwards, you might be surprised. Any time code compares an address to another address, assuming the order of the variables in memory, you've got a possible stack order dependency. I'm blanking an example (it's been almost 20 years since I worked on this stuff!), but there were definitely cases where several variables were declared on the stack, and then a comparison between a pointer and one of the variables would be used to determine whether the end of an array had been reached. Sort of like this (although it's not a positive stack example):
char *p, a[20], b;
for (p = a; p < b; p++) {...
}
Depending on the stack growth direction, and the order variables get put on the stack, this might or might not terminate at the end of the array. Of course the right way to avoid this is using sizeof(), but I saw plenty of code that didn't do it correctly.
A1 requires a mathematical proof of the model, and also requires that you show conformance between the source code and the model. It's not easy, but it's not proving the code correct.
To quote from http://www.radium.ncsc.mil/tpep/epl/epl-by-class.h tml: "The distinguishing feature of systems in this class is the analysis derived from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly implemented. This assurance is developmental in nature, starting with a formal model of the security policy and a formal top-level specification (FTLS) of the design. In keeping with the extensive design and development analysis of the TCB required of systems in class (A1), more stringent configuration management is required and procedures are established for securely distributing the system to sites. A system security administrator is supported."
There haven't been many A1 systems: GEMSOS, SCOMP, and Boeing's MLS LAN are the only that completed (see http://www.radium.ncsc.mil/tpep/epl/historical.htm l for the full list of every product). The VAX project referred to in the paper never got the A1 approval, although it was clearly designed to meet the requirements.
There are tools that find many of the exploits through source code analysis. For example, ITS4 (available from http://www.cigital.com) finds some, and RATS (available from http://www.securesoftware.com).
Coincidentally, the ITS4 paper won the "best paper" award at ACSAC (http://www.acsac.org) a few years ago... the same conference where the Multics paper that's the subject of this discussion will be presented in December!
There have been *nix systems with upward growing stacks. I worked on two (Perkin-Elmer's Edition VII, based on Version 7, and XELOX, based on System V).
There were several problems in making this work: (1) you need hardware support, (2) you end up fighting code that assumes stack growth is downwards.
WRT the first, on the PE hardware, the stack *had* to grow up, because the memory management hardware wouldn't give a proper interrupt if you ran off the bottom of a page in the middle of an instruction, but would if you ran off the top of the page. So there was no choice.
WRT the second, there was (and probably still is!) a lot of code in the UNIX utilities that assumed the order variables were put on the stack, and used that in figuring out when the end of an array had been reached. So even if it's trivial to add positive stacks to the Linux kernel, I'd bet you'll break an awful lot of applications.
And that's assuming you go to the trouble to modify the compiler to generate upward growing stacks, and recompile everything to get the new prologues/epilogues.
Ob-trivia: PE's computers were originally Interdata, which was bought by PE, which then spun them out as Concurrent Computer. Concurrent has gone through several iterations, and I'm quite certain the old systems are no longer sold.
Slashdot Mirror
Mike Nash made a snide remark that "I should also note that in contrast to the existing AES implementations that have not been through an evaluation, we plan to get our implementation evaluated to meet FIPS guidelines and requirements." Might have been true when he said it, but it's no longer true. OpenSSL completed its FIPS 140-2 approval earlier this month. See http://www.linuxelectrons.com/article.php/20060122 164238268 for an article about it; the approval (certificate #626) should be posted at http://csrc.nist.gov/cryptval/140-1/1401val2006.ht m before too long.
The author of the Business Week article missed a key point. FIPS 140 is talking about encryption, not security. You can be FIPS 140 certified, and still have completely unpatched holes. All FIPS 140 tells you is that the crypto algorithms work correctly (including random number generation, etc). Common Criteria, as others in this discussion have noted, is much more relevant. While it's not perfect (the vendor gets to pick the security features they want to claim, and they get to pick who does the approval), at least it requires a search for security vulnerabilities, and an effort to make sure that the product is architecturally sound. Sounds to me like the people at InfoGard Labs sold Business Week on the article, and they didn't have anyone who understood what the certification is about.
I'm definitely not a Microsoft fan, but this is not true. SAIC was the organization that did the NT4 C2 evaluation, and they're in the process of doing a Win2K evaluation. See http://www.radium.ncsc.mil/tpep/epl/entries/TTAP-C SC-EPL-99-001.html for the NT evaluation, and http://niap.nist.gov/cc-scheme/InEvaluation.html for the Win2K ongoing effort.
Incidentally, it was NT 3.5 that was certified without networking... NT 4.0 included networking in their evaluation. See http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EP L-95-003.html
As for fighting code that assumes stack growth downwards, you might be surprised. Any time code compares an address to another address, assuming the order of the variables in memory, you've got a possible stack order dependency. I'm blanking an example (it's been almost 20 years since I worked on this stuff!), but there were definitely cases where several variables were declared on the stack, and then a comparison between a pointer and one of the variables would be used to determine whether the end of an array had been reached. Sort of like this (although it's not a positive stack example):
char *p, a[20], b; for (p = a; p < b; p++) { ...
}
Depending on the stack growth direction, and the order variables get put on the stack, this might or might not terminate at the end of the array. Of course the right way to avoid this is using sizeof(), but I saw plenty of code that didn't do it correctly.
To quote from http://www.radium.ncsc.mil/tpep/epl/epl-by-class.h tml: "The distinguishing feature of systems in this class is the analysis derived from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly implemented. This assurance is developmental in nature, starting with a formal model of the security policy and a formal top-level specification (FTLS) of the design. In keeping with the extensive design and development analysis of the TCB required of systems in class (A1), more stringent configuration management is required and procedures are established for securely distributing the system to sites. A system security administrator is supported."
There haven't been many A1 systems: GEMSOS, SCOMP, and Boeing's MLS LAN are the only that completed (see http://www.radium.ncsc.mil/tpep/epl/historical.htm l for the full list of every product). The VAX project referred to in the paper never got the A1 approval, although it was clearly designed to meet the requirements.
There are tools that find many of the exploits through source code analysis. For example, ITS4 (available from http://www.cigital.com) finds some, and RATS (available from http://www.securesoftware.com). Coincidentally, the ITS4 paper won the "best paper" award at ACSAC (http://www.acsac.org) a few years ago... the same conference where the Multics paper that's the subject of this discussion will be presented in December!
There have been *nix systems with upward growing stacks. I worked on two (Perkin-Elmer's Edition VII, based on Version 7, and XELOX, based on System V).
There were several problems in making this work: (1) you need hardware support, (2) you end up fighting code that assumes stack growth is downwards.
WRT the first, on the PE hardware, the stack *had* to grow up, because the memory management hardware wouldn't give a proper interrupt if you ran off the bottom of a page in the middle of an instruction, but would if you ran off the top of the page. So there was no choice.
WRT the second, there was (and probably still is!) a lot of code in the UNIX utilities that assumed the order variables were put on the stack, and used that in figuring out when the end of an array had been reached. So even if it's trivial to add positive stacks to the Linux kernel, I'd bet you'll break an awful lot of applications.
And that's assuming you go to the trouble to modify the compiler to generate upward growing stacks, and recompile everything to get the new prologues/epilogues.
Ob-trivia: PE's computers were originally Interdata, which was bought by PE, which then spun them out as Concurrent Computer. Concurrent has gone through several iterations, and I'm quite certain the old systems are no longer sold.