It was a dark and stormy night. Alison was on her way home to Maine, from her fancy New Hampshire private college and it's English Lit Major L'Escapades. The wiper blades went swooka-swooka across the window. Alison cursed: thanksgiving always had such shitty weather.

@p CRACKAA-BOOOM! Lightning struck close, temporarily blinding her, and she drove into the ditch. Luckily she was unharmed, but it looked like she'd be spending a night in that weird gothic castle she just spied...

I'm almost ready to release an early version of a little game I called Bobsledder Spank Arena. I have some strange things planned for this, the least strange of them is adding tracks.

@p In Bobsledders, you race around a track and try to whack your opponent with a cricket bat. Typically you start off on opposite ends of the track, travelling in the same direction. You can reverse direction at will and there is no real right or wrong way to race around the track; you don't get any points at all for making laps, only a win by K.O.-ing your opponent. This setup is inspired by pursuit bike racing.

@p I'd like each track to be remarkable and interesting, so that may involve some extra code or other things added to them for visual effect, at least.

@p So I decided that what I really want is an auto-updater.

Now consider this: you've written some software, let's say the new Web Browser. The user chooses to trust you and install this on their system. This Web Browser then dials into a website to automatically download updates. This is the same software that was originally installed, but improved. So it's natural that the update would happen at least semi-automatically, if not totally.

@p There is a social contract between the developer and the user-- they want this particular software installed on their system.

@p Now, if you were to download and install other software onto their computer, or install an upgrade that was vastly different, they might consider this social contract broken.

Now imagine you make a game about Bobsledders that is quite popular, and there are a thousand or more players. Social contract in effect, you have an auto-updater set up so that you can easily push out improvements to the software. Of course, you have to be careful not to downgrade (e.g., break) everyone's installation, since they won't expect THAT, but it seems reasonable if you add new tracks or other bonus content that they will be glad to have it updated automatically.

Melphisto cackled loudly. His dirty T-shirt had a picture of an alligator eating a kitten, and the words MY KIND OF PURSE below it. Cracking his knuckles, he leaned back at his computer desk, in the top chamber of his giant gothic castle in Maine set against the same dark and stormy night from Part I.

@p Melphisto had managed to hack into the Bobsledders website, and uploaded a Bad Program. This would download everyone's Credit Card information and use it to purchase expensive marble from Italy for his castle.

@p You see, Melphisto had a dream. A dark dream. A dark dream that can only be dreamt by a video game nerd turned evil hacker.

@p His dream was to recreate Castlevania: Symphony of the Night. And this was going to cost MONEY.

Just like you shouldn't store passwords plaintext or weakly-hashed in your database, you shouldn't have an auto-updater that does not involve a public-key crypto system.

@p What you do as a responsible developer:

@p - Set up a local encrypted file store/container specifically for containing your private key.

@p - Put the corresponding public key IN THE UPDATER CLIENT ITSELF. These will never change, and the updater will ignore anything that isn't signed properly. The updater will never change these values (i.e., the updater won't update the updater.)

@p - When you are doing a new release, you need to sign each file that will be updated using your private key, so that it acceptable by everyone's updater.

@p This protects the people who trust you against these possibilities:

@p - Your website is hacked (happens all the time, man...)

@p - Your computer is stolen (less likely) or somehow hacked (since you will normally not even have the container with the keys on it mounted)

@p Of course, the down side is that is a lot of infrastructure for a simple updater. But this should be standard practice. Does FireFox do this? Does google chrome? Adobe? (at least adobe still ASKS if I want to update...) What about Windows Update? Debian? Ubuntu?

@p Millions of installations. One security breach. Mayhem.

@p Think about it.

I actually have an implementation of RSA that I wrote some years ago. I did this for Venture the Void, because I wanted strong key generation. What it does is take your username that you use to access your acount, adds a salt to it, MD5s it, and then creates a signature. That is your "registration code".

@p This way, there is at least no way for somebody to write a code generator that could pair up usernames with registration codes. Side note, I think this might be a reasonable approach to DRM because it doesn't require an internet connection, yet any leaked codes can be traced back to an individual customer, meaning it should be less likely that they are leaked. But whatev'.

@p Of course only in my wildest imagination are people somehow wanting to pirate Venture the Void. **Sigh** But, it looks like I'll have another use for my RSA implementation, which is cool!

@p Finally, having implemented RSA, do you know the hardest part? LONG DIVISION. Yes, by far, the hardest part was doing long division. You can avoid this if you have a BigInt class of some kind (I did not) but my actual point here is maybe it would be a fun exercise to try and code a long division algorithm. It's really surprisingly convoluted.

2011-04-21

◀ Back