Of course, copy-protection and DRM assume the buyer is a potential thief. However, a serial number system like the one present in NWN is by far the least of the evils for commercial software protection.
Game companies have to answer to the suits at the publishers whose first, second, and third concerns are how the fast the game will recoup them money with very little thought to the long haul, and likely no thought to user's systems. So, if a game publisher can get a release out that doesn't install some Draconian copy-protection system, its almost a miracle.
The NWN serial number and connection to the Gamespy servers offers a lot more than just running the game. It allows you to connect with persistant worlds, provides updates and a way of communication, and the ability to download hundreds of very high quality NWN modules, modules which are commercial quality.
Right now, NWN 1 has piracy protection done right. After patch 1.66, NWN doesn't need the CD. However if you want to play multiplayer online (and possibly automatic update, not sure), you need to have a valid CD key stored on Bioware/Gamespy's servers. Pirated CD key? It gets disabled in their database. Keygens? Yes, they fool the client, but because Bioware's servers have a list of genuine keys, it won't get far when going online.
This is enough protection to keep 95% of the people from pirating the game. The last 5% will end up finding a crack from somewhere and bypassing it, even if it entails yanking hardware cables to disable physical drives.
There is a happy medium between cards that are so small that they are easily lost (MicroSD/TransFlash), and too big for pockets (CD/DVD size). For a size engineered for general storage, I've always liked the size of 4mm cartriges or CF media, where one has enough room on the media to write a label with something fairly meaningful (date, time, format, and very terse content description.)
However, this size won't work well for devices like cellphones, PocketPCs, or PSP-like devices.
Maybe a remedy for this would be something postage stamp sized for smaller devices, and having an adapter (like what MiniSD and MicroSD cards come with) to work in a larger sized drive.
This has similar functionality like DeepFreeze, is free, has a good amount of features like rollback-ing if the machine gets spyware infected (Note: you will need to repartition to be able to use this functionality.)
It also has a great number of tools for locking down users. It may not be all what you need, but its a start, and the price is right.
Sometimes its about obsessive-compulsive lockdown freaks, but unfortunately in a number of businesses, IT *has* to be control freaks so the business doesn't get fined out of existance and people put in prison. Banks, hospitals, and other industries have to be very careful not to run afoul of HIPAA, Sox or other laws, unless they want the SEC to start coming in with a motion of discovery in hand to start auditing, and hit the company with very high fines should even a single financial E-mail have been deleted instead of being archived for seven years. No company wants the SEC or some audit board to start going through every file, folder, or hard disk, so its pretty normal for an IT group to be heavy-handed.
Windows Private Folders was released with the best of intent, but I can see 3-4 things that would have made it not so controversial.
First, document how it stores/encrypts files. Does it sit on a front-end of an archiver or is it a pass-through encryption similar to what CFS does? What encryption algorithms does it use? WPF needs a lot more documentation.
Second, release a group policy add-on that domain admins can use to restrict or block its use. MS should have released a domain policy add-on a couple weeks before the utility is available, so companies can push out a policy denying use of this utility on their network, or specifying a "master" password using a password or an EFS key for recovery reasons. This utility is good, but on computers owned by a business, this utility can create major liability and regulation issues.
Third, it needs to be written with security in mind. How is the password stored? Is the password hashed, or is the password stored by decrypting part of the file similar to what TrueCrypt does so a hash algorithm failure doesn't compromise security? What mode (ECB, CBC) is the encryption running in? Is the decrypted password stored in secure memory, or can it be swapped to disk?
Windows Private Folders isn't a bad utility, and I wish MS would release a version 2.0 of it that addresses concerns of business domains and some more documentation on how it works -- it is made for an easy to use place for home users to stick files in they don't want others to read. WPF just needed a little more planning behind its release.
Long ago, in the days of MS-DOS, there was a program that was excellent at detecting unknown MS-DOS viruses. Called Integrity Master, for maximum security one ran it from a bootable floppy, scanned files on the hard disk, and stored the file with the scanned signatures on a floppy. It wasn't SHA or MD5 hashes, but at the time it was solid security.
Then, one periodically (once or twice a week, as paranoia sees fit) ran the utility on their machine. If stuff in the MS-DOS directory was changed, it was immediately apparant. Integrity Master also was able to scan for some known viruses as well in addition to keeping a log of changed files.
We need a utility like that for Windows XP and Vista. A bootable CD or DVD that not just can understand NTFS (and NTFS's file compression), but has the necessary software to mount hard disks which are encrypted with BitLocker, PGP, SafeBoot, PointSec, WinMagic, DriveCrypt Plus Pack. The utility should also allow for username/password entry so EFS-protected files can be checked too.
This utility should use a CD or DVD to boot from, mount hard drive volumes, run checks for alternate data streams, system and nonsystem files, and finally the registry, perhaps including the encrypted parts like the SAM. It should not just save hashes of files, but perhaps have some ability to check file signatures as well (like sfc.exe and sigverif.exe do), so an update to Windows via a legitimate way doesn't set off a lot of false positives. Of course, the "manifest" file storing the file hashes on the file system would be stored on a removable USB drive, so the OS on the hard drive never has the ability to touch it.
Because this checking is done offline, a rootkit would be a lot harder to hide (unless it uses a method that the integrity scanner wasn't programmed to detect, like perhaps pointing to unallocated disk space for executable code, or hiding in an EFS-protected file.)
Of course, offline checking isn't perfect, because the machine being scanned has to be totally downed for a good amount of time which can't be done in a 24/7 environment.
There are some hurdles though. Trying to reduce the amount of false positives is one, for example. A novice user presented with a notice that a lot of files were changed likely wouldn't know what was a bad change, and what was normal for system functioning. After that, its decoding files and registry keys. Finally, if a known rootkit database was used, keeping track of how rootkits encrypt their payload, and delivering timely program updates.
I hope this proposed player doesn't require special drivers to copy files to or from it. Players from Archos, iRiver, and of course the iPod can act as USB hard disks, and one can copy files directly to and from it without using a special utility. (The iPod music files are hidden and may need retagging, but they are there. The iPod also takes a special utility to copy files to it so they are recognized, but the player itself can mount as a drive without issue.)
I refuse to buy a "mp3" player which encrypts (or worse, transcodes to a proprietary sound format) all music copied to it, where its impossible to backup the contents stored on the player. I was naiive enough to make this mistake once (its not all a loss... the player serves as a decent memory stick reader), but don't want to waste hundreds of dollars on a player that implicitly assumes in its design that the customer is a witless child or a criminal.
As soon as my current contract expires, I'm planning to purchase a T-mobile MDA, which is a rebranded HTC Wizard. It seems to have the features you want, USB connectivity (make sure you have a cable intended for USB 2.0), Bluetooth, wireless, etc.
One guy's experience getting it to work as a modem is here:
The HTC Wizard seems to have good reviews, although nothing is perfect, and even though its CPU is dual-core, people are concerned about its speed.
www.xda-developers.com has more information on this and similar phones that HTC puts out. I highly recommend checking this site out if you do decide on this phone.
The paper for a backup system is excellent -- it covers all bases of what it should be, encryption, redundancy, and robustness in case the master controller is lost. (I like your idea of the master controller storing metadata, similar to how TSM, Networker, and Retrospect store backup catalogs, and if the master is down, having the clients "recatalog" themselves to a new master.)
As for this Mac backup program, it was around around '91-'92, about the time of System 7's release. It was "merely" a control-panel extension at the time, where one installed it, rebooted, set how much HD space to give to the virtual file server, and went on your merry way. It was not intended to be scaled to an enterprise, or the public internet, but was intended for Appletalk networks (as in the old hardware and broadcast protocol which worked remarkably well in its time), instead of purchasing a dedicated Mac with Appleshare on it. (At the time, Appleshare was a server that took over the whole machine that was similar to Netware, but was intended for Macs.)
I wonder what ever happened to the company's IP and source code. Hopefully its not sitting on some old SCSI-1 drive in some clearinghouse, slowly bit-rotting away. Even worse, the code of this program ending up lost to history. Even if it were written in 680x0 assembly or THINK Pascal, it could be translated, probably with a lot of effort, to work supporting generic UNIX VFS, and Windows drives. For the Appletalk code, hopefully someone could gut it out, replace it with either a broadcast protocol, or something better for auto-discovering clients.
In the early 90s, a company made a virtual file server for networked Macs. Each client Macintosh had a file on its hard drive, and when a request was made through the driver, a number of Macs were contacted, and files were read and written to in a fairly load balanced fashion. I'm pretty sure it used some decent (think single DES) encryption at the time too, so someone couldn't just dig through the server's file on their Mac's hard disk and glean important data. It also added some redundancy, so if a Mac or two wasn't up on the network, it wouldn't kill the virtual Appleshare folder.
By chance, anyone remember this technology? I have no idea what happened to it, but it would be a blockbuster open source app if done today, and was platform independant. If done right, one could create data brokerage houses, where people could buy and sell storage space, and also reliability, where space on a RAID or server array would be of higher value than space on a laptop that is rarely on the Internet.
I recommend people rant about this bill for a bit to blow off steam, then go to www.eff.org and donate. A donation to the EFF to help protect our rights will go a long way in this battle.
If you don't want this to be the law of the land, don't just rant about the evils of the Powers That Be, but take action. Get out there and take steps. Donate to the EFF. When the EFF has a form letter to send to your senator or rep, use it, if you are a US citizen. If you are not a US citizen, and know people who are, urge them to donate and write their reps and senators.
After donating to the EFF, tell people about this bill, and why its bad. Make your arguments lucid, and by all means avoid ranting. These days if you even appear to be fanatical about something, most people will go into "smile and nod" mode, and all your effort will be for zero if not counterproductive, as people will think you are just "another one of dem dam pirates stealing software." If possible, refer people to eff.org, or a website viewed as reliable. Cnet.com.com.com.yadda has its quirks, but they do put out some very fair articles, so link to them.
I am digressing from the article by recommending privacy tools, but this is important nontheless.
Take steps to guard your privacy. Get PGP or gnupg. Learn it, and then perhaps have a keysigning gathering or two. Good steps to host one can be found here. (http://www.cryptnet.net/fdp/crypto/gpg-party.html)
If you don't like PGP, get a S/MIME key from Verisign. They have 60 day "demo" keys for free, and all they really require is your E-mail address. The link for a personal E-mail certificate is buried somewhere on their web page, but it should be present.
Consider moving your main E-mail to hushmail, cyber-rights.net, or a secure email provider. Also, consider using a privacy service offered by a provider. Some good examples of privacy providers are SecurStar (www.securstar.com), FindNot (www.findnot.com), and the one I use and highly recommend, cotse.net (www.cotse.net).
Disclaimer: I don't work for any companies listed above. I also posted in plain text, so URLs will need to be copied and pasted.
This is my two cents, but I still use Fedora, but there are a number of high quality distributions out there that may be the best fit for you.
I know that Debian and others have very good methods to ensure that packages are signed, but for me, Redhat's rpm is one of the best ways to validate a package. The signature is included with the package, and assuming I have a valid public key from the maker of the package, I can obtain rpm packages from any source, and with a rpm --checksig, check for tampering before the packages are installed. Of course, packages have a MD5 hash, which easily determines if the package was accidently corrupted.
With RedHat, Fedora, and other rpm based distributions, I can check if files have been tampered with with a single command. Its not as thorough as Tripwire, but its another way to check integrity of a system's files and permissions as originally installed. Its not perfect, as you will get lots of false positives (especially if lock down all but vital SUID files and use wrappers), but its a good guide. Checking files agains rpm's database is not secure against a hacker or program that edits the rpm database, but it provides some help should I suspect binary corruption.
Of course, I'm forgoing the fine-tuning of binaries that one gains with Gentoo or a source-based distribution, but for what I use Linux for, Fedora is fine.
I wish some camera company, instead of making some nonstandard validator service [1], would, on the camera itself, have a smartcard or Java iButton with a private key on it. Before the picture is copied to the CF card, the camera would gpg sign the image with a detached signature. Thus, on the CF card would be the raw image, or jpeg, as well as an.asc file when the signing process is completed.
Couple hurdles though. First, how does one know the signing key that is on the iButton is "trusted", and not common knowledge, like some BIOS backdoor passwords? Second, the iButton, or secure card would add space, weight, and expense to cameras. The camera business is stiff competition, a head to head price fight and feature war. The only place I can see this security feature becoming available are the high-end SLR's, the EOS 1's, and F5's of the market, where the pros want the best, and are willing and able to pay for it.
There is the problem of secure key storage. I'm not sure how hard it is to put a chip that stores securely private keys would be on a camera, in a very small form factor, other than the Dallas Semiconductors iButton, and still have it tamper-resistant.
You also have the problem that even with a tamper-resistant key, it may not be secure either -- you could intercept and modify the image before it goes to the signing module.
[1]: I don't know anything about the Canon format, though I'm glad they are putting something on the market to validate that an image is real, and not a phony. However, I just hope its more secure than what I guess it might be (md5 or SHA hash just dumped on a CF card). In any case, what Canon did is a nice step forward in ensuring the integrity of an image. Any security for images is a nice step, and kudos to Canon to having this feature available for people.
Slashdot Mirror
Of course, copy-protection and DRM assume the buyer is a potential thief. However, a serial number system like the one present in NWN is by far the least of the evils for commercial software protection.
Game companies have to answer to the suits at the publishers whose first, second, and third concerns are how the fast the game will recoup them money with very little thought to the long haul, and likely no thought to user's systems. So, if a game publisher can get a release out that doesn't install some Draconian copy-protection system, its almost a miracle.
The NWN serial number and connection to the Gamespy servers offers a lot more than just running the game. It allows you to connect with persistant worlds, provides updates and a way of communication, and the ability to download hundreds of very high quality NWN modules, modules which are commercial quality.
Right now, NWN 1 has piracy protection done right. After patch 1.66, NWN doesn't need the CD. However if you want to play multiplayer online (and possibly automatic update, not sure), you need to have a valid CD key stored on Bioware/Gamespy's servers. Pirated CD key? It gets disabled in their database. Keygens? Yes, they fool the client, but because Bioware's servers have a list of genuine keys, it won't get far when going online.
This is enough protection to keep 95% of the people from pirating the game. The last 5% will end up finding a crack from somewhere and bypassing it, even if it entails yanking hardware cables to disable physical drives.
Thumbs up, Bioware.
There is a happy medium between cards that are so small that they are easily lost (MicroSD/TransFlash), and too big for pockets (CD/DVD size). For a size engineered for general storage, I've always liked the size of 4mm cartriges or CF media, where one has enough room on the media to write a label with something fairly meaningful (date, time, format, and very terse content description.)
However, this size won't work well for devices like cellphones, PocketPCs, or PSP-like devices.
Maybe a remedy for this would be something postage stamp sized for smaller devices, and having an adapter (like what MiniSD and MicroSD cards come with) to work in a larger sized drive.
A free (WGA retina scan needed) tool from Microsoft that can help with a family computer is Microsoft's Shared Computer Toolkit.
e fault.mspx
URL:
http://www.microsoft.com/windowsxp/sharedaccess/d
This has similar functionality like DeepFreeze, is free, has a good amount of features like rollback-ing if the machine gets spyware infected (Note: you will need to repartition to be able to use this functionality.)
It also has a great number of tools for locking down users. It may not be all what you need, but its a start, and the price is right.
Sometimes its about obsessive-compulsive lockdown freaks, but unfortunately in a number of businesses, IT *has* to be control freaks so the business doesn't get fined out of existance and people put in prison. Banks, hospitals, and other industries have to be very careful not to run afoul of HIPAA, Sox or other laws, unless they want the SEC to start coming in with a motion of discovery in hand to start auditing, and hit the company with very high fines should even a single financial E-mail have been deleted instead of being archived for seven years. No company wants the SEC or some audit board to start going through every file, folder, or hard disk, so its pretty normal for an IT group to be heavy-handed.
Windows Private Folders was released with the best of intent, but I can see 3-4 things that would have made it not so controversial.
First, document how it stores/encrypts files. Does it sit on a front-end of an archiver or is it a pass-through encryption similar to what CFS does? What encryption algorithms does it use? WPF needs a lot more documentation.
Second, release a group policy add-on that domain admins can use to restrict or block its use. MS should have released a domain policy add-on a couple weeks before the utility is available, so companies can push out a policy denying use of this utility on their network, or specifying a "master" password using a password or an EFS key for recovery reasons. This utility is good, but on computers owned by a business, this utility can create major liability and regulation issues.
Third, it needs to be written with security in mind. How is the password stored? Is the password hashed, or is the password stored by decrypting part of the file similar to what TrueCrypt does so a hash algorithm failure doesn't compromise security? What mode (ECB, CBC) is the encryption running in? Is the decrypted password stored in secure memory, or can it be swapped to disk?
Windows Private Folders isn't a bad utility, and I wish MS would release a version 2.0 of it that addresses concerns of business domains and some more documentation on how it works -- it is made for an easy to use place for home users to stick files in they don't want others to read. WPF just needed a little more planning behind its release.
Long ago, in the days of MS-DOS, there was a program that was excellent at detecting unknown MS-DOS viruses. Called Integrity Master, for maximum security one ran it from a bootable floppy, scanned files on the hard disk, and stored the file with the scanned signatures on a floppy. It wasn't SHA or MD5 hashes, but at the time it was solid security.
Then, one periodically (once or twice a week, as paranoia sees fit) ran the utility on their machine. If stuff in the MS-DOS directory was changed, it was immediately apparant. Integrity Master also was able to scan for some known viruses as well in addition to keeping a log of changed files.
We need a utility like that for Windows XP and Vista. A bootable CD or DVD that not just can understand NTFS (and NTFS's file compression), but has the necessary software to mount hard disks which are encrypted with BitLocker, PGP, SafeBoot, PointSec, WinMagic, DriveCrypt Plus Pack. The utility should also allow for username/password entry so EFS-protected files can be checked too.
This utility should use a CD or DVD to boot from, mount hard drive volumes, run checks for alternate data streams, system and nonsystem files, and finally the registry, perhaps including the encrypted parts like the SAM. It should not just save hashes of files, but perhaps have some ability to check file signatures as well (like sfc.exe and sigverif.exe do), so an update to Windows via a legitimate way doesn't set off a lot of false positives. Of course, the "manifest" file storing the file hashes on the file system would be stored on a removable USB drive, so the OS on the hard drive never has the ability to touch it.
Because this checking is done offline, a rootkit would be a lot harder to hide (unless it uses a method that the integrity scanner wasn't programmed to detect, like perhaps pointing to unallocated disk space for executable code, or hiding in an EFS-protected file.)
Of course, offline checking isn't perfect, because the machine being scanned has to be totally downed for a good amount of time which can't be done in a 24/7 environment.
There are some hurdles though. Trying to reduce the amount of false positives is one, for example. A novice user presented with a notice that a lot of files were changed likely wouldn't know what was a bad change, and what was normal for system functioning. After that, its decoding files and registry keys. Finally, if a known rootkit database was used, keeping track of how rootkits encrypt their payload, and delivering timely program updates.
I hope this proposed player doesn't require special drivers to copy files to or from it. Players from Archos, iRiver, and of course the iPod can act as USB hard disks, and one can copy files directly to and from it without using a special utility. (The iPod music files are hidden and may need retagging, but they are there. The iPod also takes a special utility to copy files to it so they are recognized, but the player itself can mount as a drive without issue.)
I refuse to buy a "mp3" player which encrypts (or worse, transcodes to a proprietary sound format) all music copied to it, where its impossible to backup the contents stored on the player. I was naiive enough to make this mistake once (its not all a loss... the player serves as a decent memory stick reader), but don't want to waste hundreds of dollars on a player that implicitly assumes in its design that the customer is a witless child or a criminal.
As soon as my current contract expires, I'm planning to purchase a T-mobile MDA, which is a rebranded HTC Wizard. It seems to have the features you want, USB connectivity (make sure you have a cable intended for USB 2.0), Bluetooth, wireless, etc.
One guy's experience getting it to work as a modem is here:
http://www.pdagold.com/articles/detail.asp?a=269
The HTC Wizard seems to have good reviews, although nothing is perfect, and even though its CPU is dual-core, people are concerned about its speed.
www.xda-developers.com has more information on this and similar phones that HTC puts out. I highly recommend checking this site out if you do decide on this phone.
The paper for a backup system is excellent -- it covers all bases of what it should be, encryption, redundancy, and robustness in case the master controller is lost. (I like your idea of the master controller storing metadata, similar to how TSM, Networker, and Retrospect store backup catalogs, and if the master is down, having the clients "recatalog" themselves to a new master.)
As for this Mac backup program, it was around around '91-'92, about the time of System 7's release. It was "merely" a control-panel extension at the time, where one installed it, rebooted, set how much HD space to give to the virtual file server, and went on your merry way. It was not intended to be scaled to an enterprise, or the public internet, but was intended for Appletalk networks (as in the old hardware and broadcast protocol which worked remarkably well in its time), instead of purchasing a dedicated Mac with Appleshare on it. (At the time, Appleshare was a server that took over the whole machine that was similar to Netware, but was intended for Macs.)
I wonder what ever happened to the company's IP and source code. Hopefully its not sitting on some old SCSI-1 drive in some clearinghouse, slowly bit-rotting away. Even worse, the code of this program ending up lost to history. Even if it were written in 680x0 assembly or THINK Pascal, it could be translated, probably with a lot of effort, to work supporting generic UNIX VFS, and Windows drives. For the Appletalk code, hopefully someone could gut it out, replace it with either a broadcast protocol, or something better for auto-discovering clients.
In the early 90s, a company made a virtual file server for networked Macs. Each client Macintosh had a file on its hard drive, and when a request was made through the driver, a number of Macs were contacted, and files were read and written to in a fairly load balanced fashion. I'm pretty sure it used some decent (think single DES) encryption at the time too, so someone couldn't just dig through the server's file on their Mac's hard disk and glean important data. It also added some redundancy, so if a Mac or two wasn't up on the network, it wouldn't kill the virtual Appleshare folder.
By chance, anyone remember this technology? I have no idea what happened to it, but it would be a blockbuster open source app if done today, and was platform independant. If done right, one could create data brokerage houses, where people could buy and sell storage space, and also reliability, where space on a RAID or server array would be of higher value than space on a laptop that is rarely on the Internet.
I recommend people rant about this bill for a bit to blow off steam, then go to www.eff.org and donate. A donation to the EFF to help protect our rights will go a long way in this battle.
l )
If you don't want this to be the law of the land, don't just rant about the evils of the Powers That Be, but take action. Get out there and take steps. Donate to the EFF. When the EFF has a form letter to send to your senator or rep, use it, if you are a US citizen. If you are not a US citizen, and know people who are, urge them to donate and write their reps and senators.
After donating to the EFF, tell people about this bill, and why its bad. Make your arguments lucid, and by all means avoid ranting. These days if you even appear to be fanatical about something, most people will go into "smile and nod" mode, and all your effort will be for zero if not counterproductive, as people will think you are just "another one of dem dam pirates stealing software." If possible, refer people to eff.org, or a website viewed as reliable. Cnet.com.com.com.yadda has its quirks, but they do put out some very fair articles, so link to them.
I am digressing from the article by recommending privacy tools, but this is important nontheless.
Take steps to guard your privacy. Get PGP or gnupg. Learn it, and then perhaps have a keysigning gathering or two. Good steps to host one can be found here. (http://www.cryptnet.net/fdp/crypto/gpg-party.htm
If you don't like PGP, get a S/MIME key from Verisign. They have 60 day "demo" keys for free, and all they really require is your E-mail address. The link for a personal E-mail certificate is buried somewhere on their web page, but it should be present.
Consider moving your main E-mail to hushmail, cyber-rights.net, or a secure email provider. Also, consider using a privacy service offered by a provider. Some good examples of privacy providers are SecurStar (www.securstar.com), FindNot (www.findnot.com), and the one I use and highly recommend, cotse.net (www.cotse.net).
Disclaimer: I don't work for any companies listed above. I also posted in plain text, so URLs will need to be copied and pasted.
This is my two cents, but I still use Fedora, but there are a number of high quality distributions out there that may be the best fit for you.
I know that Debian and others have very good methods to ensure that packages are signed, but for me, Redhat's rpm is one of the best ways to validate a package. The signature is included with the package, and assuming I have a valid public key from the maker of the package, I can obtain rpm packages from any source, and with a rpm --checksig, check for tampering before the packages are installed. Of course, packages have a MD5 hash, which easily determines if the package was accidently corrupted.
With RedHat, Fedora, and other rpm based distributions, I can check if files have been tampered with with a single command. Its not as thorough as Tripwire, but its another way to check integrity of a system's files and permissions as originally installed. Its not perfect, as you will get lots of false positives (especially if lock down all but vital SUID files and use wrappers), but its a good guide. Checking files agains rpm's database is not secure against a hacker or program that edits the rpm database, but it provides some help should I suspect binary corruption.
Of course, I'm forgoing the fine-tuning of binaries that one gains with Gentoo or a source-based distribution, but for what I use Linux for, Fedora is fine.
I wish some camera company, instead of making some nonstandard validator service [1], would, on the camera itself, have a smartcard or Java iButton with a private key on it. Before the picture is copied to the CF card, the camera would gpg sign the image with a detached signature. Thus, on the CF card would be the raw image, or jpeg, as well as an .asc file when the signing process is completed.
Couple hurdles though. First, how does one know the signing key that is on the iButton is "trusted", and not common knowledge, like some BIOS backdoor passwords? Second, the iButton, or secure card would add space, weight, and expense to cameras. The camera business is stiff competition, a head to head price fight and feature war. The only place I can see this security feature becoming available are the high-end SLR's, the EOS 1's, and F5's of the market, where the pros want the best, and are willing and able to pay for it.
There is the problem of secure key storage. I'm not sure how hard it is to put a chip that stores securely private keys would be on a camera, in a very small form factor, other than the Dallas Semiconductors iButton, and still have it tamper-resistant.
You also have the problem that even with a tamper-resistant key, it may not be secure either -- you could intercept and modify the image before it goes to the signing module.
[1]: I don't know anything about the Canon format, though I'm glad they are putting something on the market to validate that an image is real, and not a phony. However, I just hope its more secure than what I guess it might be (md5 or SHA hash just dumped on a CF card). In any case, what Canon did is a nice step forward in ensuring the integrity of an image. Any security for images is a nice step, and kudos to Canon to having this feature available for people.