RE: Your source code, for sale
Hum. So my newbie-style question is, is there an eGold that can be verified, but not accessed, until a 'release' code is sent? In other words, say I'm buying some hacker-ed code and pay in egold. I don't want them to be able to 'cash' the gold until I have the code. Meanwhile, they will want to see that the gold is at least "there", even if they can't cash it yet. Is there a way to send a 'release' to an eGold (or other) payment? Better yet, a double simultaneous release feature makes thing even more interesting. -TD
From: "R.A. Hettinga" <rah@shipwright.com> To: cryptography@metzdowd.com, cypherpunks@al-qaeda.net Subject: Your source code, for sale Date: Wed, 3 Nov 2004 19:24:43 -0500
<http://www.adtmag.com/print.asp?id=10225>
- ADTmag.com
Your source code, for sale
By Mike Gunderloy
Well, maybe not yet. But what does the future hold for those who consider their source code an important proprietary asset?
Halloween this year featured more scary stuff than just ghosts and ghouls. It was also the day (at least in the Pacific time zone) when the Source Code Club posted their second Newsletter in a public Usenet group. Despite their innocent-sounding name, the Source Code Club is a group of hackers who are offering to sell the source to commercial products. Their current menu of source code for sale looks like this: * Cisco Pix 6.3.1 - $24,000 * Enterasys Dragon IDS - $19.200 * Napster - $12,000
They also claim to have the source code for many other packages that they haven't announced publicly. "If you are requesting something from a Fortune 100 company, there is a good chance that we might already have it, they say. Now, you might think this business is blatantly illegal, and no doubt it is. But that doesn't necessarily mean it's impossible. They're posting their newsletter to Usenet, probably from an Internet cafe somewhere, so that's not traceable. They'll take orders the same way, and require orders to be encrypted using their PGP key, which is at least reasonably unbreakable at the moment. (As of this writing, I don't see any encrypted messages posted to the newsgroup they use, though). For payment, they're using e-gold, which claims to protect the anonymity of its account holders.
Now, it seems reasonably likely that the Source Code Club folks will eventually get caught; going up against Cisco's resources displays at least a strong conviction of invulnerability. But even if these guys get caught, there are deeper issues here. Ten years ago, no one could have dreamed of trying to set up such a business. Ten years from now, advances in cryptography, more forms of currency circulating on the Internet, and improvements in anonymity software are likely to make it impossible to catch a similar operation.
What will it mean when hacker groups can in fact do business this way with impunity? First, it's important to note that the ability to sell wares anonymously won't necessarily imply the ability to get inventory. Your best defense against having your own source code leaked is to pay careful attention to its physical security. These days, if I were developing an important commercial product, I'd make sure there was no path between my development or build machines and the public Internet. Hackers can do lots of things, but they still can't leap over physical disconnections. Second, I'd use software that prevents temporary storage devices (like USB sticks) from connecting to the network, and keep CD and DVD burners out of the development boxes as well.
It's also worth making sure that your business doesn't depend entirely on source code. While the intellectual property that goes into making software is certainly a valuable asset, it shouldn't be your only asset. Think about ancillary services like training, support, and customization in addition to simply selling software.
Finally, note that the Source Code Club business model is based on taking advantage of people wanting to know what's in the software that they purchase. About the pix code, they say "Many intelligence agencies/government organizations will want to know if those 1's and 0's in the pix image really are doing what was advertised. You must ask yourself how well you trust the pix images you download to your appliance from cisco.com." Microsoft (among other companies) has demonstrated how to remove this particular fear factor from customers: share your source code under controlled circumstances. That doesn't mean that you need to adapt an open source model, but when a big customer comes calling, why not walk their engineers through how things work and let them audit their own areas of concern?
Given the shifting landscape of intellectual property, and the threat from groups such as the Source Code Club, these are matters you need to think about sooner rather than later. Otherwise you may wake up some morning and find that your major asset has vanished without your even knowing it was in danger.
Mike Gunderloy, MCSE, MCSD .NET, MCDBA is an independent software consultant and author working in eastern Washington. He's the editor of ADT's Developer Central newsletter and author of numerous books and articles. You can reach him at MikeG1@larkfarm.com.
This article originally appeared in the November 2004 issue of Application Development Trends.
-- ----------------- R. A. Hettinga <mailto: rah@ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Tyler Durden wrote:
Hum. So my newbie-style question is, is there an eGold that can be verified, but not accessed, until a 'release' code is sent?
proof-of-delivery protocols might help (but they're patented, as I discovered when I reinvented them a few years back).
In other words, say I'm buying some hacker-ed code and pay in egold. I don't want them to be able to 'cash' the gold until I have the code. Meanwhile, they will want to see that the gold is at least "there", even if they can't cash it yet.
Is there a way to send a 'release' to an eGold (or other) payment? Better yet, a double simultaneous release feature makes thing even more interesting.
Simultaneous release is (provably?) impossible without a trusted third party. I think this is one of the interesting applications of capabilities. Using them, you can have a TTP who is ignorant of what is running - you and your vendor agree some code that the TTP will run, using capability based code. In your case, this code would verify the eGold payment and the code (difficult to do this part with certainty, of course) and release them when both were correct. Because of the capabilities, the TTP could run the code without fear, and you would both know that it performed the desired function, but neither of you could subvert it. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
participants (2)
-
Ben Laurie
-
Tyler Durden