A good solution (if expensive and cumbersome) is a highly tamper resistant hardware device like IBM 4758 Coprocessors (been talked about on slashdot before, too lazy to look up the links)
Basically, it is a seperate computer which sits in a PCI slot. You have the program which needs the data log into the card when it is started, and whenever the program needs secret data, it passes the encrypted data into the coprocessor, which decrypts it and passes back the plaintext. The idea is that only the running program has a valid session on the card. If anyone tries to pry the secrets out of the card, it nukes itself. (Obviously you'll want at least TWO cards, with one backing up the first...) This thing is seriously paranoid. Tempature, pressure, X-Ray, vibration, time, physical shock, intrusion, and other detectors. And they seem to work. (I've put one in an X-Ray machine: it died)
Obviously there are some "gotchas" with this scheme. For one, it assumes the program is a long running one. Additionally, it assumes that access to the program itself is secured properly. Also, if you're truly paranoid you'll be using signed biniares with the checksums stored in the secured memory as well...
The cheap answer is to make a long running authorization daemon ala ssh-agent. But, the same problems of access to the machine apply.
Sure... if you want to never see a dime or a replacement. Seriously, I spent 5 months of my life once trying t oget UPS to fix a machine which arrived with holes in the shipping container, and had been dropped so hard components inside has shattered. (like the motherboard, oppsss)
I do. But I wouldn't laugh at them. This sort of thing happens all the time. I'm a developer, who gets called out on some especially bad support calls sometime. Usually the problem is that the management (at the customer end) won't let their people listen to us, because they think they know the problem better. I actually have customers who I contact informally through back channels when something critical goes wrong, because it's a hell of a lot easier than dealing with all the policital shit. Having a solid gold service contract is worthless, if the managers of the people running the machines hamstring them at every turn.
Geeks work well together, PHB's work(?) well together, but geeks and PHB's.... watch out.
Oh yeah... I forgot! Where I live (Texas), we have "fun" open container laws too. You can have them, so long as the driver isn't holding it. And that's a relatively new restriction I beleive
"There will also be unusual safeguards. Since more than a few riders here are bound to be sloshed by more than a few drinks, every stop will be walled and sealed in glass, with doors timed to open only at the moment trains arrive -- so no one in a stupor falls from a platform." "We had to keep the nature of the city in mind," said Todd Walker, director of communications for the company managing the monorail."
How come I've never lived in a city where the public contractors freely admit building around the general drunkeness of the public? "Don't trust your citizens around sharp objects, electricity, or fire? No problem in our town!"
"While traveling on planes or trains, people could enjoy streaming video input or interactive games..."
Yeah, I think I want a buch of spark gap generators on a plane with me. The streaming video will be good for that time when we're taking off and landing and they make me turn off all electronics including my PDA to reduce (possible) navigation interference.
Granted, I don't think most electronics put out enough RF interference to cause problems, but why chance it? What if the transmitter get kicked, droped, jostled, or otherwise "detuned"?
My mom is the director of a public library, and I know for a fact she regularly refuses requests to disclose the borrowing habits of suspects. I beleive there is precedence for this. I remember a little something about a supreme court judge and video rentals...
Great... I'm all for letting them charge people who massive abuse the service, but if they are going to do this, can I have a few things like port 80, 443, and 1443 back? I'm not willing to pay $150 a month to have a "business" account for the 3 people a month who might come to my page (hell, I'm not even Google...)
Why doesn't it burn? I know diamonds don't unless you subject them to really high temps, but this sounds a lot more like the allotrope(sp?) of carbon I'm a little more used to, which burns nicely...
Perhaps the point is that the user might not want to have to buy a seperate box for each of their customers. Maybe Sun wouldn't be so upset if they had a similiar technology. (Which they don't, to my knowledge... at least not to the same level of scalability)
Maybe the great working is playing the games for a living... looking at bare hex/assembly all day sounds a bit too much like debugging other people's code to me. (Which is only fun if they are around to make fun of...) And god help these guys if the DMCA nazis get a hold of them... "We liscenced you the game, we didn't say you could look at it."
I work in IBM development, I was dealing with a guy who works support in another state, who was at a customer's site in another country. Obviously, the powers that be don't want to have lots of nice free data sharing between all these segments. Especially since the product I work on is security related. (And before anyone jumps on me about the lack of security of uServ, I was up till 3 AM last night running back and forth between two sites in multiple cars do a key exchange ceremony using physical tokens for a bank. I understand when using a lightweight system like this is okay.)
Sure, in my earlier example we could have moved the data in question using existing channels, but you'd be going from three different platforms, three differnt OSes. Not only that, but a lot of people don't have things like SSH installed. SMB is kinda WinTel based, which doesn't help me much. NFS has lots of fun things like UDP. Add firewalls into the mix (because we're going between development, support, and customers) Did I mention dynamic IP's? And proxies?
Granted, I'm not a big Java supporter, and would prefer a SSH/SCP tunnel, BUT, when I needed the data fast, this was a HELL of a lot easier than setting up a more traditional method. Have you noticed the shift towards "Web Services" in the software world? It's not because doing everythin of HTTP/HTTPS ports is the best way, but because damn near everyone has a solution in place to allow that sort of traffic to flow. uServ simply exploits that.
Oh, about our "jacked up Intranet": Yes, it can be "jacked up" but it's a lot better thought out than any other place I've been. Even the parts running Token Ring. (ewww...)
While debugging a nasty client issue, my co-worker said: "Well, I've got these 100 megs worth of logs..." Which would really help me out, but because of all sorts of internal networking issues they would be hard to get. Then he introduced me to uServ. "Here, try this..." And there the logs were. Saved my butt.
There is a huge difference between "simplifying their job" and "simplifying the product". Writing a wrapper around existing code is fine. Sometimes even good.
More times than not I see inferior solutions written because it was easier in the short term.
I work in cryptography. Obviously for math intensive stuff like this, something like C/C++ is much more appropriate most the time. A lot of times I see developers "cheap out" by using some of the API's built into Java to do annoying parsing tasks. That's great for Java programs which are leveraging those technology, but NOT acceptable for an underlying engine which is already written mostly in C/C++. And yes, I've seen this happen. I've spent three hours writing and intergrating a C program to replace a section of code like this recently, and increased throughput by %250. All because someone wanted to save a few minutes the first time out.
Things You Need To Do To Get Things Working
I strongly disagree will you here. The largest problem the product I'm talking about has is installation issues. We've got 15 pre-reqs. Big, heavy things. I've been flown all over the world to help major customers simply get the damn thing installed. I'm not support, I'm a developer. That is bad news. And I'm sure you can imagine what a nice impression it makes on a customer to have the product go belly up before it even does something useful. A little more time in the development cycle to save the customer time on install is priceless in my opinion.
Having worked on a rather large chunk of code which my group "inherited" from another stable of developers who liked to "learn new technology" I have a few words of caution:
Using multiple languages is a Good Thing(tm) if, and only if, they are not used to take shortcuts, learn on the job, or avoid writing "hard" code. I'm a rabid anti-Java zealot, not because I think the language is bad, but because it is often used in places it shouldn't be. I've had to maintain a lot of fairly poor quality Java code because the previous developer was learning it at the time. The number of times I've seen a really bad use of Java because it was easier than writing good C is depressing. On the other hand, I've seen people build vast empires of C to replace what clearly should have been a nice Java or Perl program, simply because they perfer C, and have a personal adgenda. (heh... I've never done that.... nooo....)
The other fun thing to consider is that if you're calling interpretated languages, you need to remember that the burden for prereq's on your target platform is going to be huge.
Using the right tool for the job is a nice thing, but I've found a lot of developers (myself included) tend to want to use the language they are currently tinkering with wherever possible. The old saying about "when your only tool is a hammer..." extends nicely to "when the closest tool is a hammer..."
I've flown in and out of Newark 4 times since the 11th. This last flight (on Friday afternoon) The pilot pointed out an AWACS flying perpendicular to us. Cool. It did seem that security was a bit higher than before at Newark too.
Cryptography is a funny field. It's sorta like an intellectual game of chicken. The "best" crypto is almost always the more established algorithms. (These days things like 3DES and RSA) The rational behind this is that the basic principles are sound, leaving only brute force attacks. The nightmare scenario is a "clever" attack. If I dis cover that the WizzBang-2000 scheme is easy to crack if I just divided my cats age, and multiply by 6, then life starts to suck for the WizzBang-2000 users. And quickly.
So here, we worry about the speed of brute force. With factoring based crypto, it's fairly easy to move the keysize out a tiny amount and reap huge returns. Symmetric based systems are harder, and often need a redesign/re-evaluation. Such as the DES -> AES migration underway now. 56 to 128 bits isn't quite enough for the truely paranoid.
The chicken part is deciding if someone else has come up with something clever and just not disclosed it. (The big boogy man here is governmental bodies...) Think Engima during WWII.
Personally, I tend to think that there are enough people working "outside the fence" on crypto that if a major established algorithm was broken, we'd all know shortly thereafter. (And imagine the chaos...)
More to the point, if an established algorithm is flawed and the parties holding the flaw are governmental, they'd either have to tell almost no one, (because of the danger of a leak) or tell everyone in the government to use some new algorithm. (Which would set off alarm bells for sure.)
Even the "new" algorithms proposed as canidates for the new AES (now decided as Rija... whatever) were mostly based on the same old "known hard" problems.
Along similiar lines, elliptic curves kinda scare me because the math isn't as studied, and I personally think there is more of a chance of an "off the wall" solution to the "hard" problem. With factoring, pretty much everyone since the dawn of math has been hammering on it. (Elliptic has been hammered for a few hundred years I think, but not nearly as intensely.)
"The Man" wants a backdoor because it's cheaper than a huge beowulf cluster.
Gee... This ougtha show dem der terries... Screw with our country, and we know just how to respond. Ha! Try to make an impact by doing sometime to affect the things which make us American... We'll show you! We can take away the things you don't like about our country all by ourself! So there!
It's a question of convincing the right management. In my experience the idiots pushing the "time to market" BS tend to push it just long enough to overcommit the next development cycle, make a bunch of promises, collect the commission, and move on to a new position. Leaving those of us in the trenches to bring some substance to the vaporware some idiot MBA promised to a customer.
I firmly believe there needs to be a tighter commitment from management to an individual product. Product development is carried out one cycle behind the sales cycle. I realize there is always a need for fresh capital, but the "sell-then-develop" model is a dangerous game. In my experience, when management realizes it has over-extended, it simply "transitions" to a new product, and lets development take the hit
Senior management, the people who have a stake in the company, need to hold middle management more responsible for quality. They also need to realize that without MBA's are replacable, an experienced developer is much more valueable.
Let me see if I got this right... The guy is willing to part with his domain for less than $6000 and BattleBot.com is fighting him? How much does it cost to hire an evil corporate lawyer? Certainly more than that.
Slashdot Mirror
their toasters would want to very badly
how their toast cook?
wires, red and glowing
So how do they feel about Apache? I mean, IBM will sell it to you can IBM HTTPD, but it's still Apache. Or Java? Or... grrr
A good solution (if expensive and cumbersome) is a highly tamper resistant hardware device like IBM 4758 Coprocessors (been talked about on slashdot before, too lazy to look up the links)
Basically, it is a seperate computer which sits in a PCI slot. You have the program which needs the data log into the card when it is started, and whenever the program needs secret data, it passes the encrypted data into the coprocessor, which decrypts it and passes back the plaintext. The idea is that only the running program has a valid session on the card. If anyone tries to pry the secrets out of the card, it nukes itself. (Obviously you'll want at least TWO cards, with one backing up the first...) This thing is seriously paranoid. Tempature, pressure, X-Ray, vibration, time, physical shock, intrusion, and other detectors. And they seem to work. (I've put one in an X-Ray machine: it died)
Obviously there are some "gotchas" with this scheme. For one, it assumes the program is a long running one. Additionally, it assumes that access to the program itself is secured properly. Also, if you're truly paranoid you'll be using signed biniares with the checksums stored in the secured memory as well...
The cheap answer is to make a long running authorization daemon ala ssh-agent. But, the same problems of access to the machine apply.
Sure... if you want to never see a dime or a replacement. Seriously, I spent 5 months of my life once trying t oget UPS to fix a machine which arrived with holes in the shipping container, and had been dropped so hard components inside has shattered. (like the motherboard, oppsss)
I actually have customers who I contact informally through back channels when something critical goes wrong, because it's a hell of a lot easier than dealing with all the policital shit.
Having a solid gold service contract is worthless, if the managers of the people running the machines hamstring them at every turn.
Geeks work well together, PHB's work(?) well together, but geeks and PHB's.... watch out.
Oh yeah... I forgot! Where I live (Texas), we have "fun" open container laws too. You can have them, so long as the driver isn't holding it. And that's a relatively new restriction I beleive
"We had to keep the nature of the city in mind," said Todd Walker, director of communications for the company managing the monorail."
How come I've never lived in a city where the public contractors freely admit building around the general drunkeness of the public? "Don't trust your citizens around sharp objects, electricity, or fire? No problem in our town!"
Yeah, I think I want a buch of spark gap generators on a plane with me. The streaming video will be good for that time when we're taking off and landing and they make me turn off all electronics including my PDA to reduce (possible) navigation interference.
Granted, I don't think most electronics put out enough RF interference to cause problems, but why chance it? What if the transmitter get kicked, droped, jostled, or otherwise "detuned"?
My mom is the director of a public library, and I know for a fact she regularly refuses requests to disclose the borrowing habits of suspects. I beleive there is precedence for this. I remember a little something about a supreme court judge and video rentals...
Great... I'm all for letting them charge people who massive abuse the service, but if they are going to do this, can I have a few things like port 80, 443, and 1443 back? I'm not willing to pay $150 a month to have a "business" account for the 3 people a month who might come to my page (hell, I'm not even Google...)
Why doesn't it burn? I know diamonds don't unless you subject them to really high temps, but this sounds a lot more like the allotrope(sp?) of carbon I'm a little more used to, which burns nicely...
Perhaps the point is that the user might not want to have to buy a seperate box for each of their customers. Maybe Sun wouldn't be so upset if they had a similiar technology. (Which they don't, to my knowledge... at least not to the same level of scalability)
Maybe the great working is playing the games for a living... looking at bare hex/assembly all day sounds a bit too much like debugging other people's code to me. (Which is only fun if they are around to make fun of...) And god help these guys if the DMCA nazis get a hold of them... "We liscenced you the game, we didn't say you could look at it."
I work in IBM development, I was dealing with a guy who works support in another state, who was at a customer's site in another country. Obviously, the powers that be don't want to have lots of nice free data sharing between all these segments. Especially since the product I work on is security related. (And before anyone jumps on me about the lack of security of uServ, I was up till 3 AM last night running back and forth between two sites in multiple cars do a key exchange ceremony using physical tokens for a bank. I understand when using a lightweight system like this is okay.)
Sure, in my earlier example we could have moved the data in question using existing channels, but you'd be going from three different platforms, three differnt OSes. Not only that, but a lot of people don't have things like SSH installed. SMB is kinda WinTel based, which doesn't help me much. NFS has lots of fun things like UDP. Add firewalls into the mix (because we're going between development, support, and customers) Did I mention dynamic IP's? And proxies?
Granted, I'm not a big Java supporter, and would prefer a SSH/SCP tunnel, BUT, when I needed the data fast, this was a HELL of a lot easier than setting up a more traditional method. Have you noticed the shift towards "Web Services" in the software world? It's not because doing everythin of HTTP/HTTPS ports is the best way, but because damn near everyone has a solution in place to allow that sort of traffic to flow. uServ simply exploits that.
Oh, about our "jacked up Intranet": Yes, it can be "jacked up" but it's a lot better thought out than any other place I've been. Even the parts running Token Ring. (ewww...)
While debugging a nasty client issue, my co-worker said: "Well, I've got these 100 megs worth of logs..." Which would really help me out, but because of all sorts of internal networking issues they would be hard to get. Then he introduced me to uServ. "Here, try this..." And there the logs were. Saved my butt.
Mmm.... federally monitored bedroom... Wonder if McAfee is in on this yet.
Um... AIX uses /usr/lpp/packagename for nearly everything. /usr/bin contains symlinks.
Especially stuff IBM ships.
Dunno about the other OSes...
Yikes! Fortunately, I'm still employed. :)
There is a huge difference between "simplifying their job" and "simplifying the product". Writing a wrapper around existing code is fine. Sometimes even good.
More times than not I see inferior solutions written because it was easier in the short term.
I work in cryptography. Obviously for math intensive stuff like this, something like C/C++ is much more appropriate most the time. A lot of times I see developers "cheap out" by using some of the API's built into Java to do annoying parsing tasks. That's great for Java programs which are leveraging those technology, but NOT acceptable for an underlying engine which is already written mostly in C/C++. And yes, I've seen this happen. I've spent three hours writing and intergrating a C program to replace a section of code like this recently, and increased throughput by %250. All because someone wanted to save a few minutes the first time out.
Things You Need To Do To Get Things Working
I strongly disagree will you here. The largest problem the product I'm talking about has is installation issues. We've got 15 pre-reqs. Big, heavy things. I've been flown all over the world to help major customers simply get the damn thing installed. I'm not support, I'm a developer. That is bad news. And I'm sure you can imagine what a nice impression it makes on a customer to have the product go belly up before it even does something useful. A little more time in the development cycle to save the customer time on install is priceless in my opinion.
Having worked on a rather large chunk of code which my group "inherited" from another stable of developers who liked to "learn new technology" I have a few words of caution:
Using multiple languages is a Good Thing(tm) if, and only if, they are not used to take shortcuts, learn on the job, or avoid writing "hard" code. I'm a rabid anti-Java zealot, not because I think the language is bad, but because it is often used in places it shouldn't be. I've had to maintain a lot of fairly poor quality Java code because the previous developer was learning it at the time. The number of times I've seen a really bad use of Java because it was easier than writing good C is depressing. On the other hand, I've seen people build vast empires of C to replace what clearly should have been a nice Java or Perl program, simply because they perfer C, and have a personal adgenda. (heh... I've never done that.... nooo....)
The other fun thing to consider is that if you're calling interpretated languages, you need to remember that the burden for prereq's on your target platform is going to be huge.
Using the right tool for the job is a nice thing, but I've found a lot of developers (myself included) tend to want to use the language they are currently tinkering with wherever possible. The old saying about "when your only tool is a hammer..." extends nicely to "when the closest tool is a hammer..."
I've flown in and out of Newark 4 times since the 11th. This last flight (on Friday afternoon) The pilot pointed out an AWACS flying perpendicular to us. Cool. It did seem that security was a bit higher than before at Newark too.
Dude, pack my stuff, I'm moving.... now I just need to buy a bunch of those power convertors. Damn metric electricity!
Cryptography is a funny field. It's sorta like an intellectual game of chicken. The "best" crypto is almost always the more established algorithms. (These days things like 3DES and RSA) The rational behind this is that the basic principles are sound, leaving only brute force attacks. The nightmare scenario is a "clever" attack. If I dis cover that the WizzBang-2000 scheme is easy to crack if I just divided my cats age, and multiply by 6, then life starts to suck for the WizzBang-2000 users. And quickly.
... whatever) were mostly based on the same old "known hard" problems.
So here, we worry about the speed of brute force. With factoring based crypto, it's fairly easy to move the keysize out a tiny amount and reap huge returns. Symmetric based systems are harder, and often need a redesign/re-evaluation. Such as the DES -> AES migration underway now. 56 to 128 bits isn't quite enough for the truely paranoid.
The chicken part is deciding if someone else has come up with something clever and just not disclosed it. (The big boogy man here is governmental bodies...) Think Engima during WWII.
Personally, I tend to think that there are enough people working "outside the fence" on crypto that if a major established algorithm was broken, we'd all know shortly thereafter. (And imagine the chaos...)
More to the point, if an established algorithm is flawed and the parties holding the flaw are governmental, they'd either have to tell almost no one, (because of the danger of a leak) or tell everyone in the government to use some new algorithm. (Which would set off alarm bells for sure.)
Even the "new" algorithms proposed as canidates for the new AES (now decided as Rija
Along similiar lines, elliptic curves kinda scare me because the math isn't as studied, and I personally think there is more of a chance of an "off the wall" solution to the "hard" problem. With factoring, pretty much everyone since the dawn of math has been hammering on it. (Elliptic has been hammered for a few hundred years I think, but not nearly as intensely.)
"The Man" wants a backdoor because it's cheaper than a huge beowulf cluster.
I can only hope this is a joke...
It's a question of convincing the right management. In my experience the idiots pushing the "time to market" BS tend to push it just long enough to overcommit the next development cycle, make a bunch of promises, collect the commission, and move on to a new position. Leaving those of us in the trenches to bring some substance to the vaporware some idiot MBA promised to a customer.
I firmly believe there needs to be a tighter commitment from management to an individual product. Product development is carried out one cycle behind the sales cycle. I realize there is always a need for fresh capital, but the "sell-then-develop" model is a dangerous game. In my experience, when management realizes it has over-extended, it simply "transitions" to a new product, and lets development take the hit
Senior management, the people who have a stake in the company, need to hold middle management more responsible for quality. They also need to realize that without MBA's are replacable, an experienced developer is much more valueable.
Let me see if I got this right... The guy is willing to part with his domain for less than $6000 and BattleBot.com is fighting him? How much does it cost to hire an evil corporate lawyer? Certainly more than that.