I have a number of games from the early MS-DOS days that I legally bought, but can't run. The most common reason is copy protection (the second most common reason is the game runs too fast to be usable). While I am not sure of the legaility (especially with tricky EULA's, which existed even back then), it seems to me like I would be well within my rights to use a version with the copy protection ripped out.
So this raise the question, if we had purchased (licensed,/whatever) of the abadoned software, do I have the right to modify it so it actually works? Do I have the right to use someone else's modification (regradless of the reason they made the modification in the first place, i.e. warez).
Aside: Somewhere on a 360K floppy, I still have a few gladiators that I worked hard on (Avalon Hill's Galtactic Gladiators). Since GG was coded in BASIC (using that sophisticated built-in Microsoft basic protection), it was not too hard to fix. I was able to remove the protection, but I had to add a lot of delays before the game became playable on a i386(otherwise things would move too fast to see).
I had the same need, low cost or free Web Hosting for a non-profit (my traffic is probably even lower than yours). I tried a number of different companies, but I found the small local providers were the most helpful.
"Got.net" provided their $20/month service for free, and also setup the domain name for free. We still had to pay the domain name registration fees.
You miss the point. SMDI, encouraged by the DMCA, puts tamper detection into the recording device. A side effect of that tamper detection is that is could prevent you from accessing your own recording.
As a hardware security expert, I find it to be a plausable real-world scenario.
Actually, there is another method that banks solve some of the application level security problems. It is called a hardware security module (HSM). It performs sensitive transactions like PIN Verification, so that keys and PINS do not appear in the "clear" (unencrypted) outside of the HSM.
There are different solutions for different problems. Don't make the mistake of thinking an outside hacker attack is the most dangerous. When you are worried about insider fraud, SSL and IPSEC are mostly useless.
I developed a credit card processing gateway in Australia...
Reading this post, I started off appalled. Than I realized they were talking about credit card numbers, not PINS. The credit card data is semi-public information, and there are a number of people that have a legitimate need to see credit card data with our current system. The requirements to protect credit card information are comparatively recent (people only started worrying about carbon copies in the late 80's). This has worked OK, until the internet started connecting everything.
Wrong or right, the credit card system relies upon weak authorization systems (what you have, not what you know or what you are). This means they have a high rate of fraud, which is factored into the system costs. Given today's point of view, I'm not surprised that they found a lot of weaknesses. Start with the first and worst credit card problem, which QuantamG did not event think to criticize: the authentication data is public (kind of like the US designing the Social Security Number without a check-digit). If they used some additional data (like a PIN), many of the issues he complains about would be moot (you could find customer lists, but not really commit fraud). The whole credit card was designed around this principle.
Perhaps ironically, Australia has some of the best requirements for POS security when it comes to PIN, the AS-2805 standard. This covers both physical and logical security for POS terminals that handles PINS (often called PINpads). Since AS-2805 was so stringent, Australia ended up with some of the most secure (and most expensive) PINpads around. The PIN encryption was single-DES based, but so was everyone else. Since anything on the magnetic stripe was considered public data, the POS requirements did not spend any effort trying to keep it secret. They only added message integrity protection in the early 90's. A great deal of time and effort was spent on key management (still a major issue today, even with public keys).
An Aside: I worked for a company that used to sell some of the most secure PINpads around. We left the business, because among other reasons, security as a feature did not sell (we found superior usability and security were not worth a $5 premium for a $200 product in the USA!).
Canada (Interact) started out with good security requirements, but kept on relaxing them requirements so the influential members could buy cheaper, and less secure PINpads. I think Interact gave up on their original PINpad security requirements about the time we left the business. Australia, unless they have caved since, was one of the few places that required all PINpads to be at the highest level of security. We never sold POS terminals there, because the market was too small to justify the expense of implementing AS-2805 routines into our product.
Unless your application happens to exactly match (identical queries and similar data sets) TPC-C is worthless.
Although this is exaggerated flame-bait, I even kind of agree with it. Let me restate this in more reasonable terms: The OLTP benchmark TCP/C won't be that useful to someone who wants to know about non-OLTP performance.
Hmm, seems kind of self evident when put that way. TCP/C is useful for a large subclass of OLTP server functions, such as ATM (bank machine) transactions, telco call records, etc. They share the same basic needs (acquiring and processing a small amount of data in a high volume real-time transaction environment).
There are TPC benchmarks that give the vendors much less information (so they can't optimize specifically for the benchmarks at the expense of everything else), but literally no vendors run them, since they can't control the results as well. TPC-C munging is a pretty well understood science these days.
I think this is mixing two concepts:
(1) Optimizations that are not real-world.
(2) Benchmarks that have different purposes.
All benchmarks are subject to optimization, the question is does this also result in a real-world increase. TPC/A and TPC/C have a surprisingly good track record, probably because of work done by the TPC council. The TPC/C benchmark is not perfect, but it has done better at resisting non-real-world optimization than any other benchmark I can think of. Don't forget that TPC/C has been around for quite a while, and has had some high stakes behind it (meaning people have been highly motivated to achieve good results).
Now it may be that TCP/C optimizations hurt performance for something other than OLTP processing, but that is a different story. Remember the/. conversations about databases: sometimes you want a full ACID database with rollback, and sometimes they are not worth the overhead and extra design.
I'm taking some pains about this, because/. conversations can become too narrow. Most viewpoints seem to come from people who are running their own *nix box, or from the administrator running a small scale web, application, and print server. Just because the tool does not work for you, does not mean is useless.
Perhaps it is just my bias from my days of working at Tandem computers, but I've always considered TPC to be one of the better benchmarks. True, there have been some problems with non-real world optimizations (Oracle had some great schemes in the early 90s), but I think actually much less problems than almost any other benchmark.
I think two primary benefits of TPC is that they audit the results, and they have a fairly realistic "cost" calculation. The cost calculation includes not only the up front purchase price of the equipment and software, but also the maintenance fees for the first several years (forget if it was 3 or 5). That stops vendors from giving away the software cheap, but making a bundle selling support each year.
No benchmark is perfect, and an important thing to remember is what the benchmark is for. The TPC A through C measures "Online Transaction Processing" (OLTP), which are reactively simple transactions. This means the TPC/C gives you a good idea of server throughput, but tells you nothing about client performance for instance. That means it won't be applicable to many types of functions performed by computers. For instance, the TPC/C does not use many types of database operations (the data warehousing oriented TPC/D does a better job of wringing out a database). Another issue with TPC is that they are complex to setup and perform. It costs the company a lot of money to make a competitive TPC benchmark, or at least in all the cases I know of. These are typically complex systems, with many processors, I/O options, etc., and it takes a while to tune the system.
As an interesting aside, it might be neat to track how long it took to setup the TCP test. This could give a clue about how easy it is to tune and maintain your systems with complex loads. Of course this would never work in the real world, if nothing else it would give companies that had performed the TCP test before an unfair advantage.
Let me explain why I mentioned my Tandem Computers bias (ex-employee, but I still have some enthusiasm). Tandem held the fastest TCP/C score for over a year in the mid-90's. Since the Tandem NSK (Non-Stop Kernel) systems were optimized for OLTP throughput, this is not that much of a surprise. The fact they were a cost leader with a fully fault tolerant system was. The reason they could do that was because of the massive-parallel design of the NSK systems (99+% of CPU performance at the 100+ CPU level). Eventually prices dropped enough on the regular systems, that they became cheaper (as you might expect) than the fully fault tolerant solution. I suspect Tandem NSK (now owned by Compaq) could take the overall TCP/C lead anytime it wanted, just not at the best price/performance ratio.
Compaq/Tandem is doing a more complex type of benchmarking, since most real world computers have to be good at more than just one thing (like OLTP). They have an impressive demo where a single system image processes the equivalent of the 5 largest teleco companies' transactions (1.2 billions calls per day), while also supporting customer support and data warehousing functions on a 90 day database at the same time (www.compaq.com/zle). Don't try this with a symmetric multi-processing system!
The final aside: Tandem NSK runs a message based OS that is very similar to a micro-kernel. Those people suggesting a micro-kernel can not perform adequately, have too limited of a range of experience. Won't pretend that Tandem had it easy getting NSK to perform, but getting maximum performance in a normal OS is not easy either.
The Fresh Aire radio interview show has an interview of Singapore's first prime minister -- Lee Kuan Yew that mentioned this very subject. Singapore had numerous dialets, as well as Chinesse and English. In the 1960's they decided to make English the offical language.
There was a brief discussion on the introduction techniques, including the concept of language specific schools (English was taught as a second language in all non-English schools).
The FORTEZZA card is potentially a two-factor solution, which is a good thing. Of course there are a few issues:
1) Is the crypto card normally kept with the machine? If it is, the thief would make off with the card too. This eliminates the "what you have".
2) How is the "activating" password processed? I'm not familiar with the details of the FORTEZZA card, but one would hope the application that gathers the password takes care that it won't appear in the disk swap file, or anywhere else for that matter.
3) Is the encryption done on or off the card? Most smartcard/token solutions only keep the keys on the card, since the chip is too slow for bulk encryption. The original FORTEZZA card did the cryptography itself (part of the reason the government liked it, they did not have to let the algorithm be available in software). This turned out to be pretty expensive (one of the reasons contributing to the FORTEZZA failure).
4) Assuming they get the FORTEZZA card, and it contains all the keys needed to decrypt the disk, you won't be safe from well funded opponents. Any hardware can be broken; given enough money and resources... it is just amazing what a good chip lab can do these days. As usual you have to take into account the value and lifetime of what you are protecting.
All in all, I suspect the FORTEZZA card is a good solution, but check out the details. The crypto algorithm (as mentioned elsewhere) is relatively untested, but I'll take a poorly inspected NSA algorithm over most other people's algorithms almost every time (unless I'm trying to hide something from the NSA:-)
The randomness of the keys are going to be a limitation in these systems. It is a safe prediction that exhaustive attack methods are going to be applied against the key generation process (assuming they are known), instead of the key space itself.
First, think of your bank account. It's real numbers stored in a computer, numbers that other people shouldn't be able to see or change. So, these numbers need to be protected. You can't effectively encrypt them (without leaving the keys sitting there: the computer needs to get to them) so the issue is purely one of protecting them. Give a computer scientist the task of protecting some vital data and she will set about designing a secure system. It's a fun problem to solve. Well, that's all passwords are: data that needs protecting.
We can do a little better than leaving the keys "sitting there". The typical bank uses a hardware security module (HSM), and the keys only appear in the clear inside the HSM. That stops the hacker from running away with the keys. The Personal-Identification-Number (PIN) is already protected in most banks using the methods I describe below.
The sense of the message, as described, is still correct. If the hacker can make the host call the HSM to decrypt the numbers, than you still have not protected the numbers. That is part of what makes logical security design so much fun:-)
The HSM design approach is to not provide a generic decrypt function. Instead you figure out how the numbers have to be used, and provide narrow functionality that performs just what needs to be done, and nothing more. You also tie the HSM transaction with cryptographic audits. Even if a hacker (or insider) gets into the system, they can't stealthily modify the data (it will be detected during the crypto stage). All they can do is perform a limited set of functions on the protected data (using the HSM), which can be monitored and undone (using the audit trail).
In practice, using an HSM, you can make a system much stronger than the post implied. Note that I am just talking about confidentiality and integrity here, the HSM does not help against deletion and DoS attacks.
MY former company exported all kinds of electronic stuff to countries all over the world. Each required an export license.
Don't confuse normal export licenses with ITAR controlled products. The US Government (used to, and still does to a lesser extent) treat encryption like a monition. Unless the company from your example was selling missiles, military components, etc. or cryptography, it is not a valid comparison. Did they meet with the NSA several times a year?
My favorite story (which was true during much of the 1990's) is the data sheet. This innocent 4 page, 8.5x11" glossy sales brochure was treated by the government like it was a blue print to build a military weapon. Our chief competitor in the banking HSM market was based out of England. It took 2-3 months, background checks, and lots of paperwork before we could send the data sheet to a potential customer in the United Kingdom (the country of our primary competitor)!
Thats right, the US was protecting the rest of the world from marketing material. True, the data sheet did have some important technical information (AC had to be 110 or 220, 50 or 60 cycles, etc.). Seems like this requirement became relaxed around 1996 or so. The encryption regulations have changed many times. Except when they don't... I'm still waiting to see when the latest changes gloriously announced by the President will actually work their way through the bureaucracy!
My former company was the USA market leader for hardware security modules (HSM) that perform back-end encryption for banking ATM transactions. I was the chief software architect, and can categorically state that there is no NSA backdoor in that product.
That is not to say that the NSA did not have some influnce on the design (back before the rules changed and put the FBI and State Department in charge of export procedures). The NSA really discouraged (using the export license stick) the use of triple-DES. The fact they discouraged certain designs types is pretty much public knowledge.
What is less known, is that the NSA did a through examination of the product. In order to get an export license, the NSA also had to review the product - all specifications, code, manufacturing diagrams, samples devices. They also requested and got our future product plans. It is my impression that the NSA did this future product research everywhere they could.
So this means the NSA knew all details of any crypto product that was being exported. They knew the specifications, and in some cases the future product directions. I never heard of a case where the NSA would come back after a product evaluation and say "you have a security hole". In summary, even without a formal backdoor, they have (had?) a lot of knowledge.
PS: When I hear about ex-NSA members joining public companies, I wonder how many of my company's ideas (forcefully obtained by USA export regulations) went with them. You might say, the NSA was all knowing, so their was nothing to steal. The truth is that the NSA was really into military uses (they supposedly passed up developing public key algorithms because they did not have any use for them). Don't under estimate the value of a practical commercial related applied cryptography use.
One thing to remember about formal certifications, they are only good for the version they were evaluated. If you make any bug fix, even a minor one, you have to do another *expensive* evaluation.
I've heard estimates for the initial ITSEC level 7 or FIPS level 4 certification at upwards of a million US Dollars. Evaluating a changed versions are in the tens, to hundreds of thousands of US Dollars. Sure some of this will be cheaper if the design and code changes are open source, but the evaluation labs are not cheap.
This is the primary reason that formally certified products (both software and hardware based) will remain pretty scarce. In the real world, you tend to get systems where some parts have been formally evaluated (for instance - the boot code for a security device). Other parts have been evaluated from time to time (the application program on the security device).
The other thing that happens is the formally certified part gets "stale". For really expensive certificaitons (like a Level A1 OS), it only gets done once, and customers are forever stuck with that version. How would you like to use a 15 year old version of an Operating System? That is part of the price you pay for the highest level of security.
Another important consideration is that true security depends upon the whole environment. I've put Hardware-Security-Module products through the German central bank certification process (ZKA). Just because customer X's environment is certified with the product, does not mean customer Y will automatically get a certification. True, the certification will probably be somewhat shorter (and less costly) if the product has been part of another certified environment.
This post reminds me of a recent story about Priceline customers who are complaining because the airline tickets they buy have ridiculous limitations. It occurs to me that this is not a technology limitation, just an implementation problem.
Right now, when a consumer uses the reverse auction to purchase something, like an airline ticket, Priceline does not provide them with a good enough way to specify what they will accept. A better design would allow the purchaser to specify the terms of the purchase upfront, in other words: specify their own contract.
INAL, but I understand an important part of contract law is determining what to do when things go wrong. If things always went right, contracts would rarely be needed, or least they would be much simpler. So I'm not proposing that everyone should write his or her own contracts. What should happen is that an educated consumer could select a consumer friendly contract from a pool of choices.
The reverse auction process should allow the real cost of the contract clauses to be determined. The corporations currently have so much power, that they can put very restrictive clauses into the contract without much impact. I think a reverse auction of this type would reduce the massive advantage a corporation currently has in a typical consumer purchase transaction. Of course, I'd expect that a consumer might have to pay slightly more if they specify an advantageous contract.
I've both worked on, and later managed out-sourced programming projects. Most of these have been with local firms, but I've done one Silicon Valley/India project. I've had a number of successful projects, but it takes a lot of work. Here are some things to look out for:
Perhaps the single most valuable tip... require code reviews and conduct them jointly (at least the first few, and occasionally thereafter). All sorts of reasons to do this.
* It will give you early warning if your design document is inadequate.
* It will help with cross-training (bring contractors up to speed, and help internal staff learn new technology).
* You can make sure they are following your internal standards (like documentation).
* It will also give you an idea of the competence the programmers and organization.
There is almost always some type of learning curve. Make sure you account for the internal support time.
Your company will "loose" knowledge by outsourcing. If this knowledge is key to your business, you probably don't want to out-source it. If you have to out-source (for instance you don't have internal resources who can do that), look at a formal training relationship. Note that I've often see training attempted, but it has a high failure rate.
Out-sourcing usually means that you have to improve your documentation, so don't forget to account for the extra time if you don't normally do good documentation. If this is new technology, you probably won't know enough to have a good design upfront, so plan on doing the project in phases so you can correct and clarify issues with the original design document.
You need excellent acceptance criteria. Formalized test plans are best. They can be written either internally or externally, but must be jointly reviewed for completeness.
In summary, it can work if it is done carefully. The successful out-sourcing projects usually have the following characteristics (in my experience):
* Long term relationship with out-source firm
* Projects are not core business
* Projects are reviewed, weaknesses identified and corrected with next project. It takes continual work.
Recalling my experiences with a VAX, I'm reminded of a well intentioned project gone awry. The University of California at Santa Cruz had a VAX farm, running BSD of course (since BSD was developed at UC Berkeley, a sister campus).
The "public" system -ucscb- was an old PDP/10 (with magnetic core memory) had achieved the highest Unix load numbers I had seen up to this point. They would not allow screen-graphic games (like rogue, etc.) to be played until after 6pm. Every night just after 6pm, the load numbers would shoot up to 20-30 (meaning, supposedly, the equivalent of 20-30 people using the full power of the computer at the same time, means the 100 or so users logged on were running serious CPU hogs)! They eventually replaced this machine with a 68020 based mini-computer (they had no funds to buy a new public system, but figured out the reduced maintenance costs would break-even in less than a year).
The highest real world load numbers I ever saw came from an undergrad class. It was some type of intro to data algorithms class, and the TA?s wanted to make the class interesting. They introduced the concept of Alpha-Beta pruning, a technique used for game AI. They supplied an Othello program, with vital parts of the AI removed. The idea was that the students would rewrite the AI. Great concept, but they did not quite realize what they were letting loose.
This was a traditional UC big undergrad class ? around 220 people. They were assigned 3 VAX 11/750 (about half the speed of the classic 11/780). Picture 70 people per VAX, compiling 3000 line C programs at the same time. I personally saw load numbers of 60, and was told it hit a peak of 79. It took vi about 10 minutes to open a file, and a simple line down (pressing the ?j? key) took over a minute. Needless to say, quite a few people never managed to finish that project!
I find it ironic that the poster complains about a 3 week turn-around. When a reputable company gets a bug report, there are several things they should do:
* Research to make sure it does not contain other bugs of the same type. * Design the fix, making sure it does not introduce new bugs * Implement the fix * Test the fix * Distribute the fixed product/patch
Three weeks is actually pretty good under many circumstances. Your overnight patches may look responsive, but don't complain if the end product is buggy! If it is not a matter of life and death, why not give them time to fix the problem the right way?
2. When IDEs on "other platforms" were going for hundreds (sometimes hundreds and hundreds) of dollars, metrowerks offered a "discover" package that compiled C, C++, Java and Pascal for $100.
Borland has a long history of providing low cost tools. When Turbo Pascal first came out, it took the market by storm because of it's cost (not to forget about speed of compliation). Borland has consistently provided tools below $100 at least into the mid-90's.
I don't know if they will keep up this tradition, but in the past they have been a strong advocate of low cost tools.
Before Microsoft bought it, CP/M was a piece of crap.
Actually, Microsoft did not buy CP/M. They licensed the rights for QDOS (a CP/M clone), and quickly violated those rights as part of the IBM deal. I'd like to see solid details on this, but from memory... several years later the authors of QDOS sued Microsoft for license infringement, and received a "hefty" sum as a settlement (seem to recall $50M).
The original IBM PC was sold with a choice of three operating systems, one was from the makers of CP/M (Digital Research). The other two were Microsoft's DOS and IBM's repackaged version of Microsoft's DOS. My opinions: I felt IBM DOS 1.1 was considerably short of CP/M during the same timeframe. But to be fair they put a lot of work into DOS and by 1983, DOS v2.0 was roughly equal to CP/M. I would not say it was clearly better until v3.3 (came out around 1984 I think), and that was largely because of good 3rd party support and some real nifty TSR's that CP/M did not support. In otherwords, IBM's pull with the market, not Microsoft's "inovation" of DOS.
No longer did one have to shell out in the 10k's for a UNIX workstation.
I know what you are trying to say, but this was not a good way of saying it. There were numerous other "personal computers" on the market at the time: Commodore PET, Apple II, TRS-80, etc. The IBM PC came out 4-5 years later in 1981. I don't recall the exact release dates of the Commodore 64, Atari 800, and TI 99; but they may also have been out a year or two earlier than the IBM PC.
Finally, I'm not aware of any "UNIX Workstations" ($10K or not) that were around in 1981 when the IBM PC was introduced. UNIX was there, but it ran on mini and mainframe computers. SUN was not even founded until 1982. I don't know of anyone at that time who had the radical idea of using a "standard" (UNIX) operating system instead of a home-built one. As an aside, there is no doubt that MS DOS was influnced by UNIX (CP/M probably owed a bit to it too). The most visible influnce was in the MS DOS shell and "helper" applications.
...then there's a lot of components you have to trust...
Good point, and it is true for all security system designes. Actually most of the really high security systems are not just "software". The most common type is the "Hardware Security Module" (HSM) industry, which includes secure sections in everything from smartcard to tamper-resistant boxes.
You can use off-the-shelve compontents without them also having to be fully ceritified, so long as the way they are used is carefully constrained. The FIPS 140-1 standard shows some good examples. If the compiler is used in a trusted environment, and produces objects that are run in a limited set of circumstances, you can evaluate those circumstances in place of trying to get a certified complier.
For example, if you are building firmware for a smartcard, you don't have to have complete trust of the compiler. This presumes the smartcard has a reasonably small amount of funtionality, is well tested, and has the code masked at the factory.
The only acess to the card is through the API you designed and tested. Since there are limited features, and the access is not through a generic environment; you can rule out all but the most targeted and sneaky trojan attacks. Even these can easily be found if you inspect compiled code (a routine practice at HSM companies).
As the project gets bigger and more complex, and as you start dealing with untrusted hardware; these types of attacks become much easier.
Security specifications are different than a normal system. Although I generally agree with the comments in #119, they miss the point that Gene Spafford was trying to make. Most systems are just happy to have the system work correctly, a point mentioned in post #121.
Security systems are only as good as their weakest link. Good security system design requires a step past working correctly. They have to work correctly and not work wrongly, in other words: no bugs even if a very intelligent opponent is trying purposely to break things!
Needless to say, making things without bugs is very hard, and making things that resist attacks is even harder. You have to consider the real world and the whole environment, not just the sub-system you happen to be working on at the time. For examples, remember the smartcard hacking techniques like subjecting the computer to microwaves or extreme temperatures as a method to force the system to leak information.
I won't claim the open source community could not achieve a secure design, but it requires some very different ways of working on the project. That leads to several rules of good security system design:
1)Know what you want to do (this is the main point of good requirements). 1a) Fully understand all errors, and decide how to handle them. 2) Keep things as simple as possible. 2a) Break down complex problems into simple sub-systems. 2b) Minimize the amount of interacting sub-systems
Slashdot Mirror
So this raise the question, if we had purchased (licensed,/whatever) of the abadoned software, do I have the right to modify it so it actually works? Do I have the right to use someone else's modification (regradless of the reason they made the modification in the first place, i.e. warez).
Aside: Somewhere on a 360K floppy, I still have a few gladiators that I worked hard on (Avalon Hill's Galtactic Gladiators). Since GG was coded in BASIC (using that sophisticated built-in Microsoft basic protection), it was not too hard to fix. I was able to remove the protection, but I had to add a lot of delays before the game became playable on a i386(otherwise things would move too fast to see).
"Got.net" provided their $20/month service for free, and also setup the domain name for free. We still had to pay the domain name registration fees.
You miss the point. SMDI, encouraged by the DMCA, puts tamper detection into the recording device. A side effect of that tamper detection is that is could prevent you from accessing your own recording.
As a hardware security expert, I find it to be a plausable real-world scenario.
There are different solutions for different problems. Don't make the mistake of thinking an outside hacker attack is the most dangerous. When you are worried about insider fraud, SSL and IPSEC are mostly useless.
Reading this post, I started off appalled. Than I realized they were talking about credit card numbers, not PINS. The credit card data is semi-public information, and there are a number of people that have a legitimate need to see credit card data with our current system. The requirements to protect credit card information are comparatively recent (people only started worrying about carbon copies in the late 80's). This has worked OK, until the internet started connecting everything.
Wrong or right, the credit card system relies upon weak authorization systems (what you have, not what you know or what you are). This means they have a high rate of fraud, which is factored into the system costs. Given today's point of view, I'm not surprised that they found a lot of weaknesses. Start with the first and worst credit card problem, which QuantamG did not event think to criticize: the authentication data is public (kind of like the US designing the Social Security Number without a check-digit). If they used some additional data (like a PIN), many of the issues he complains about would be moot (you could find customer lists, but not really commit fraud). The whole credit card was designed around this principle.
Perhaps ironically, Australia has some of the best requirements for POS security when it comes to PIN, the AS-2805 standard. This covers both physical and logical security for POS terminals that handles PINS (often called PINpads). Since AS-2805 was so stringent, Australia ended up with some of the most secure (and most expensive) PINpads around. The PIN encryption was single-DES based, but so was everyone else. Since anything on the magnetic stripe was considered public data, the POS requirements did not spend any effort trying to keep it secret. They only added message integrity protection in the early 90's. A great deal of time and effort was spent on key management (still a major issue today, even with public keys).
An Aside: I worked for a company that used to sell some of the most secure PINpads around. We left the business, because among other reasons, security as a feature did not sell (we found superior usability and security were not worth a $5 premium for a $200 product in the USA!).
Canada (Interact) started out with good security requirements, but kept on relaxing them requirements so the influential members could buy cheaper, and less secure PINpads. I think Interact gave up on their original PINpad security requirements about the time we left the business. Australia, unless they have caved since, was one of the few places that required all PINpads to be at the highest level of security. We never sold POS terminals there, because the market was too small to justify the expense of implementing AS-2805 routines into our product.
Although this is exaggerated flame-bait, I even kind of agree with it. Let me restate this in more reasonable terms: The OLTP benchmark TCP/C won't be that useful to someone who wants to know about non-OLTP performance.
Hmm, seems kind of self evident when put that way. TCP/C is useful for a large subclass of OLTP server functions, such as ATM (bank machine) transactions, telco call records, etc. They share the same basic needs (acquiring and processing a small amount of data in a high volume real-time transaction environment).
There are TPC benchmarks that give the vendors much less information (so they can't optimize specifically for the benchmarks at the expense of everything else), but literally no vendors run them, since they can't control the results as well. TPC-C munging is a pretty well understood science these days.
I think this is mixing two concepts:
(1) Optimizations that are not real-world.
(2) Benchmarks that have different purposes.
All benchmarks are subject to optimization, the question is does this also result in a real-world increase. TPC/A and TPC/C have a surprisingly good track record, probably because of work done by the TPC council. The TPC/C benchmark is not perfect, but it has done better at resisting non-real-world optimization than any other benchmark I can think of. Don't forget that TPC/C has been around for quite a while, and has had some high stakes behind it (meaning people have been highly motivated to achieve good results).
Now it may be that TCP/C optimizations hurt performance for something other than OLTP processing, but that is a different story. Remember the /. conversations about databases: sometimes you want a full ACID database with rollback, and sometimes they are not worth the overhead and extra design.
I'm taking some pains about this, because /. conversations can become too narrow. Most viewpoints seem to come from people who are running their own *nix box, or from the administrator running a small scale web, application, and print server. Just because the tool does not work for you, does not mean is useless.
I think two primary benefits of TPC is that they audit the results, and they have a fairly realistic "cost" calculation. The cost calculation includes not only the up front purchase price of the equipment and software, but also the maintenance fees for the first several years (forget if it was 3 or 5). That stops vendors from giving away the software cheap, but making a bundle selling support each year.
No benchmark is perfect, and an important thing to remember is what the benchmark is for. The TPC A through C measures "Online Transaction Processing" (OLTP), which are reactively simple transactions. This means the TPC/C gives you a good idea of server throughput, but tells you nothing about client performance for instance. That means it won't be applicable to many types of functions performed by computers. For instance, the TPC/C does not use many types of database operations (the data warehousing oriented TPC/D does a better job of wringing out a database). Another issue with TPC is that they are complex to setup and perform. It costs the company a lot of money to make a competitive TPC benchmark, or at least in all the cases I know of. These are typically complex systems, with many processors, I/O options, etc., and it takes a while to tune the system.
As an interesting aside, it might be neat to track how long it took to setup the TCP test. This could give a clue about how easy it is to tune and maintain your systems with complex loads. Of course this would never work in the real world, if nothing else it would give companies that had performed the TCP test before an unfair advantage.
Let me explain why I mentioned my Tandem Computers bias (ex-employee, but I still have some enthusiasm). Tandem held the fastest TCP/C score for over a year in the mid-90's. Since the Tandem NSK (Non-Stop Kernel) systems were optimized for OLTP throughput, this is not that much of a surprise. The fact they were a cost leader with a fully fault tolerant system was. The reason they could do that was because of the massive-parallel design of the NSK systems (99+% of CPU performance at the 100+ CPU level). Eventually prices dropped enough on the regular systems, that they became cheaper (as you might expect) than the fully fault tolerant solution. I suspect Tandem NSK (now owned by Compaq) could take the overall TCP/C lead anytime it wanted, just not at the best price/performance ratio.
Compaq/Tandem is doing a more complex type of benchmarking, since most real world computers have to be good at more than just one thing (like OLTP). They have an impressive demo where a single system image processes the equivalent of the 5 largest teleco companies' transactions (1.2 billions calls per day), while also supporting customer support and data warehousing functions on a 90 day database at the same time (www.compaq.com/zle). Don't try this with a symmetric multi-processing system!
The final aside: Tandem NSK runs a message based OS that is very similar to a micro-kernel. Those people suggesting a micro-kernel can not perform adequately, have too limited of a range of experience. Won't pretend that Tandem had it easy getting NSK to perform, but getting maximum performance in a normal OS is not easy either.
The Fresh Aire radio interview show has an interview of Singapore's first prime minister -- Lee Kuan Yew that mentioned this very subject. Singapore had numerous dialets, as well as Chinesse and English. In the 1960's they decided to make English the offical language.
There was a brief discussion on the introduction techniques, including the concept of language specific schools (English was taught as a second language in all non-English schools).
http://search.npr.org/freshair/dayFA.cfm?display =day&todayDate=10%2F24%2F2000
1) Is the crypto card normally kept with the machine? If it is, the thief would make off with the card too. This eliminates the "what you have".
2) How is the "activating" password processed? I'm not familiar with the details of the FORTEZZA card, but one would hope the application that gathers the password takes care that it won't appear in the disk swap file, or anywhere else for that matter.
3) Is the encryption done on or off the card? Most smartcard/token solutions only keep the keys on the card, since the chip is too slow for bulk encryption. The original FORTEZZA card did the cryptography itself (part of the reason the government liked it, they did not have to let the algorithm be available in software). This turned out to be pretty expensive (one of the reasons contributing to the FORTEZZA failure).
4) Assuming they get the FORTEZZA card, and it contains all the keys needed to decrypt the disk, you won't be safe from well funded opponents. Any hardware can be broken; given enough money and resources... it is just amazing what a good chip lab can do these days. As usual you have to take into account the value and lifetime of what you are protecting.
All in all, I suspect the FORTEZZA card is a good solution, but check out the details. The crypto algorithm (as mentioned elsewhere) is relatively untested, but I'll take a poorly inspected NSA algorithm over most other people's algorithms almost every time (unless I'm trying to hide something from the NSA :-)
The randomness of the keys are going to be a limitation in these systems. It is a safe prediction that exhaustive attack methods are going to be applied against the key generation process (assuming they are known), instead of the key space itself.
It was a 64-bit key. NSA reduced it to 56-bits, and changed the sboxes around.
We can do a little better than leaving the keys "sitting there". The typical bank uses a hardware security module (HSM), and the keys only appear in the clear inside the HSM. That stops the hacker from running away with the keys. The Personal-Identification-Number (PIN) is already protected in most banks using the methods I describe below.
The sense of the message, as described, is still correct. If the hacker can make the host call the HSM to decrypt the numbers, than you still have not protected the numbers. That is part of what makes logical security design so much fun :-)
The HSM design approach is to not provide a generic decrypt function. Instead you figure out how the numbers have to be used, and provide narrow functionality that performs just what needs to be done, and nothing more. You also tie the HSM transaction with cryptographic audits. Even if a hacker (or insider) gets into the system, they can't stealthily modify the data (it will be detected during the crypto stage). All they can do is perform a limited set of functions on the protected data (using the HSM), which can be monitored and undone (using the audit trail).
In practice, using an HSM, you can make a system much stronger than the post implied. Note that I am just talking about confidentiality and integrity here, the HSM does not help against deletion and DoS attacks.
Don't confuse normal export licenses with ITAR controlled products. The US Government (used to, and still does to a lesser extent) treat encryption like a monition. Unless the company from your example was selling missiles, military components, etc. or cryptography, it is not a valid comparison. Did they meet with the NSA several times a year?
My favorite story (which was true during much of the 1990's) is the data sheet. This innocent 4 page, 8.5x11" glossy sales brochure was treated by the government like it was a blue print to build a military weapon. Our chief competitor in the banking HSM market was based out of England. It took 2-3 months, background checks, and lots of paperwork before we could send the data sheet to a potential customer in the United Kingdom (the country of our primary competitor)!
Thats right, the US was protecting the rest of the world from marketing material. True, the data sheet did have some important technical information (AC had to be 110 or 220, 50 or 60 cycles, etc.). Seems like this requirement became relaxed around 1996 or so. The encryption regulations have changed many times. Except when they don't... I'm still waiting to see when the latest changes gloriously announced by the President will actually work their way through the bureaucracy!
That is not to say that the NSA did not have some influnce on the design (back before the rules changed and put the FBI and State Department in charge of export procedures). The NSA really discouraged (using the export license stick) the use of triple-DES. The fact they discouraged certain designs types is pretty much public knowledge.
What is less known, is that the NSA did a through examination of the product. In order to get an export license, the NSA also had to review the product - all specifications, code, manufacturing diagrams, samples devices. They also requested and got our future product plans. It is my impression that the NSA did this future product research everywhere they could.
So this means the NSA knew all details of any crypto product that was being exported. They knew the specifications, and in some cases the future product directions. I never heard of a case where the NSA would come back after a product evaluation and say "you have a security hole". In summary, even without a formal backdoor, they have (had?) a lot of knowledge.
PS: When I hear about ex-NSA members joining public companies, I wonder how many of my company's ideas (forcefully obtained by USA export regulations) went with them. You might say, the NSA was all knowing, so their was nothing to steal. The truth is that the NSA was really into military uses (they supposedly passed up developing public key algorithms because they did not have any use for them). Don't under estimate the value of a practical commercial related applied cryptography use.
I've heard estimates for the initial ITSEC level 7 or FIPS level 4 certification at upwards of a million US Dollars. Evaluating a changed versions are in the tens, to hundreds of thousands of US Dollars. Sure some of this will be cheaper if the design and code changes are open source, but the evaluation labs are not cheap.
This is the primary reason that formally certified products (both software and hardware based) will remain pretty scarce. In the real world, you tend to get systems where some parts have been formally evaluated (for instance - the boot code for a security device). Other parts have been evaluated from time to time (the application program on the security device).
The other thing that happens is the formally certified part gets "stale". For really expensive certificaitons (like a Level A1 OS), it only gets done once, and customers are forever stuck with that version. How would you like to use a 15 year old version of an Operating System? That is part of the price you pay for the highest level of security.
Another important consideration is that true security depends upon the whole environment. I've put Hardware-Security-Module products through the German central bank certification process (ZKA). Just because customer X's environment is certified with the product, does not mean customer Y will automatically get a certification. True, the certification will probably be somewhat shorter (and less costly) if the product has been part of another certified environment.
Right now, when a consumer uses the reverse auction to purchase something, like an airline ticket, Priceline does not provide them with a good enough way to specify what they will accept. A better design would allow the purchaser to specify the terms of the purchase upfront, in other words: specify their own contract.
INAL, but I understand an important part of contract law is determining what to do when things go wrong. If things always went right, contracts would rarely be needed, or least they would be much simpler. So I'm not proposing that everyone should write his or her own contracts. What should happen is that an educated consumer could select a consumer friendly contract from a pool of choices.
The reverse auction process should allow the real cost of the contract clauses to be determined. The corporations currently have so much power, that they can put very restrictive clauses into the contract without much impact. I think a reverse auction of this type would reduce the massive advantage a corporation currently has in a typical consumer purchase transaction. Of course, I'd expect that a consumer might have to pay slightly more if they specify an advantageous contract.
Perhaps the single most valuable tip... require code reviews and conduct them jointly (at least the first few, and occasionally thereafter). All sorts of reasons to do this.
* It will give you early warning if your design document is inadequate.
* It will help with cross-training (bring contractors up to speed, and help internal staff learn new technology).
* You can make sure they are following your internal standards (like documentation).
* It will also give you an idea of the competence the programmers and organization.
There is almost always some type of learning curve. Make sure you account for the internal support time.
Your company will "loose" knowledge by outsourcing. If this knowledge is key to your business, you probably don't want to out-source it. If you have to out-source (for instance you don't have internal resources who can do that), look at a formal training relationship. Note that I've often see training attempted, but it has a high failure rate.
Out-sourcing usually means that you have to improve your documentation, so don't forget to account for the extra time if you don't normally do good documentation. If this is new technology, you probably won't know enough to have a good design upfront, so plan on doing the project in phases so you can correct and clarify issues with the original design document.
You need excellent acceptance criteria. Formalized test plans are best. They can be written either internally or externally, but must be jointly reviewed for completeness.
In summary, it can work if it is done carefully. The successful out-sourcing projects usually have the following characteristics (in my experience):
* Long term relationship with out-source firm
* Projects are not core business
* Projects are reviewed, weaknesses identified and corrected with next project. It takes continual work.
The "public" system -ucscb- was an old PDP/10 (with magnetic core memory) had achieved the highest Unix load numbers I had seen up to this point. They would not allow screen-graphic games (like rogue, etc.) to be played until after 6pm. Every night just after 6pm, the load numbers would shoot up to 20-30 (meaning, supposedly, the equivalent of 20-30 people using the full power of the computer at the same time, means the 100 or so users logged on were running serious CPU hogs)! They eventually replaced this machine with a 68020 based mini-computer (they had no funds to buy a new public system, but figured out the reduced maintenance costs would break-even in less than a year).
The highest real world load numbers I ever saw came from an undergrad class. It was some type of intro to data algorithms class, and the TA?s wanted to make the class interesting. They introduced the concept of Alpha-Beta pruning, a technique used for game AI. They supplied an Othello program, with vital parts of the AI removed. The idea was that the students would rewrite the AI. Great concept, but they did not quite realize what they were letting loose.
This was a traditional UC big undergrad class ? around 220 people. They were assigned 3 VAX 11/750 (about half the speed of the classic 11/780). Picture 70 people per VAX, compiling 3000 line C programs at the same time. I personally saw load numbers of 60, and was told it hit a peak of 79. It took vi about 10 minutes to open a file, and a simple line down (pressing the ?j? key) took over a minute. Needless to say, quite a few people never managed to finish that project!
I find it ironic that the poster complains about a 3 week turn-around. When a reputable company gets a bug report, there are several things they should do:
* Research to make sure it does not contain other bugs of the same type.
* Design the fix, making sure it does not introduce new bugs
* Implement the fix
* Test the fix
* Distribute the fixed product/patch
Three weeks is actually pretty good under many circumstances. Your overnight patches may look responsive, but don't complain if the end product is buggy! If it is not a matter of life and death, why not give them time to fix the problem the right way?
Borland has a long history of providing low cost tools. When Turbo Pascal first came out, it took the market by storm because of it's cost (not to forget about speed of compliation). Borland has consistently provided tools below $100 at least into the mid-90's.
I don't know if they will keep up this tradition, but in the past they have been a strong advocate of low cost tools.
http://www.compumentor.org/
Actually, Microsoft did not buy CP/M. They licensed the rights for QDOS (a CP/M clone), and quickly violated those rights as part of the IBM deal. I'd like to see solid details on this, but from memory... several years later the authors of QDOS sued Microsoft for license infringement, and received a "hefty" sum as a settlement (seem to recall $50M).
The original IBM PC was sold with a choice of three operating systems, one was from the makers of CP/M (Digital Research). The other two were Microsoft's DOS and IBM's repackaged version of Microsoft's DOS. My opinions: I felt IBM DOS 1.1 was considerably short of CP/M during the same timeframe. But to be fair they put a lot of work into DOS and by 1983, DOS v2.0 was roughly equal to CP/M. I would not say it was clearly better until v3.3 (came out around 1984 I think), and that was largely because of good 3rd party support and some real nifty TSR's that CP/M did not support. In otherwords, IBM's pull with the market, not Microsoft's "inovation" of DOS.
No longer did one have to shell out in the 10k's for a UNIX workstation.
I know what you are trying to say, but this was not a good way of saying it. There were numerous other "personal computers" on the market at the time: Commodore PET, Apple II, TRS-80, etc. The IBM PC came out 4-5 years later in 1981. I don't recall the exact release dates of the Commodore 64, Atari 800, and TI 99; but they may also have been out a year or two earlier than the IBM PC.
Finally, I'm not aware of any "UNIX Workstations" ($10K or not) that were around in 1981 when the IBM PC was introduced. UNIX was there, but it ran on mini and mainframe computers. SUN was not even founded until 1982. I don't know of anyone at that time who had the radical idea of using a "standard" (UNIX) operating system instead of a home-built one. As an aside, there is no doubt that MS DOS was influnced by UNIX (CP/M probably owed a bit to it too). The most visible influnce was in the MS DOS shell and "helper" applications.
Try looking at http://www.pbm.com/~lindahl/merchants/index.armor. html
Good point, and it is true for all security system designes. Actually most of the really high security systems are not just "software". The most common type is the "Hardware Security Module" (HSM) industry, which includes secure sections in everything from smartcard to tamper-resistant boxes.
You can use off-the-shelve compontents without them also having to be fully ceritified, so long as the way they are used is carefully constrained. The FIPS 140-1 standard shows some good examples. If the compiler is used in a trusted environment, and produces objects that are run in a limited set of circumstances, you can evaluate those circumstances in place of trying to get a certified complier.
For example, if you are building firmware for a smartcard, you don't have to have complete trust of the compiler. This presumes the smartcard has a reasonably small amount of funtionality, is well tested, and has the code masked at the factory.
The only acess to the card is through the API you designed and tested. Since there are limited features, and the access is not through a generic environment; you can rule out all but the most targeted and sneaky trojan attacks. Even these can easily be found if you inspect compiled code (a routine practice at HSM companies).
As the project gets bigger and more complex, and as you start dealing with untrusted hardware; these types of attacks become much easier.
Security specifications are different than a normal system. Although I generally agree with the comments in #119, they miss the point that Gene Spafford was trying to make. Most systems are just happy to have the system work correctly, a point mentioned in post #121.
Security systems are only as good as their weakest link. Good security system design requires a step past working correctly. They have to work correctly and not work wrongly, in other words: no bugs even if a very intelligent opponent is trying purposely to break things!
Needless to say, making things without bugs is very hard, and making things that resist attacks is even harder. You have to consider the real world and the whole environment, not just the sub-system you happen to be working on at the time. For examples, remember the smartcard hacking techniques like subjecting the computer to microwaves or extreme temperatures as a method to force the system to leak information.
I won't claim the open source community could not achieve a secure design, but it requires some very different ways of working on the project. That leads to several rules of good security system design:
1)Know what you want to do (this is the main point of good requirements).
1a) Fully understand all errors, and decide how to handle them.
2) Keep things as simple as possible.
2a) Break down complex problems into simple sub-systems.
2b) Minimize the amount of interacting sub-systems
No one said this was easy. :-)