The problem is that there is no good single solution. Just like there is no one single lock that would secure a building. You have to have multiple backup solutions, with some being onsite for fast rebuilds in case of RAID failure or malware infection, and slower, offline backups that takes a bit to get to, but are insulated from a severe and through attack by a blackhat or malware.
First stage: Consider mirroring of OS partitions, and if your OS/filesystem supports snapshots, have it do those often. One can do this in Windows Server 2003 and 2008 quite easily per volume, Vista is a bit harder, but it does have some snapshot functionality. This layer is for recovering deleted/corrupted files or directories without having to reach for restore media.
Second stage: Have an external drive connected for Time Machine, Vista's file backup, Acronis TrueImage, and set to backup at least nightly. This layer is intended for completely rebuilding a machine due to hardware failure, or to restore files that are not stored as a filesystem snapshot.
Third stage: Have a dedicated backup server, running some network backup program (Retrospect, Backup Exec, Networker, TSM), and make sure the backup server not just is hardened from network attacks because it has all the crown jewels, but the drives are encrypted so its theft would not be catastrophic. One can use EncFS, loopback mounts, TrueCrypt, BitLocker, PGP, or program of choice for this. I leave the data volumes unencrypted for speed, encrypt the boot volume, and use the backup program's encryption, so if someone steals the RAID array, it will be little more than a hardware gain. On the backup server, have a DVD writer available, ISOs of OS media, and a database of CD keys so a machine can be installed and reactivated without having to hunt for the right string of characters.
Fourth stage: Disk to disk to tape. You have a tape drive (or a library) attached to the backup server. This way, machines can back to a RAID array, minimizing the backup window, but you can get backups moved to tape or perhaps external hard disks for safekeeping and offline storage. The advantage of tape is that you can physically set the cartridges read only, so should the backup server get infected, it cannot alter data on the media. Same with tape drives that use WORM functionality like DLTIce. Consider a good tape rotation, and offsiting the tapes. Also, when offsiting a bin of tapes, don't forget to include a DVD with media and license keys for both the OS and the backup program to be able to start restores. Tape is expensive, but there are removable hard disk solutions to mimic the good part of tape usage such as what RDX technology sells (such as write protection).
Fifth stage: Offsite backups. I have had great luck with Mozy, and you can specify it to use a dedicated keyfile for encryption, so even if someone breaks into the Mozy account, without that keyfile, the data is useless to them. Of course, I keep a copy of the keyfile offsite and encrypted with a long passphrase to prevent chicken/egg scenarios.
Sixth stage: Critical files and documents (tax records, legal info) copied to a DVD-R or USB flash drive every quarter or so and stored in a format decodable in any platform. This includes the Mozy keyfiles, the BitLocker recovery keys, ISO images of the TrueCrypt volume recovery disks and header files, PGP keys, and any other cryptographic info. Since gpg files are decodable by almost any OS out there, I use that. This way, should real disaster happen, at least critical records would be recoverable.
Seventh stage: Hard copy printouts of critical documents (payroll, tax records) every six months to year. This even includes source code trees. These are boxed and stuck in storage. This is the extreme of offline copying, but it ensures that data will be around and usable should something like a long nationwide power outage occour (on the order of months to years). This is rather extreme, but it allows a company to go back to paper
The only place where using VMs for projects might not work well are applications (including games) which require Direct X and high performance. VMWare Workstation has some experimental support for DX9, but if one wants to play a game, probably their best bet would be a second drive with an OS that isn't used for anything other than gaming.
This idea of using VMs could make for some interesting security on laptops that have TPM chips:
First, the laptop would be secured with BitLocker. This would provide two things, first, hardware and MBR tamper detection. Someone messes with the laptop while its not attended, it won't boot and ask for the recovery key. Second, BitLocker is transparant once it boots. No need to worry about an additional passphrase (though the recovery key should be kept someplace secure).
The main OS here is mainly used just as an enlighted host for the other VMs. Using Hyper-V or VMWare Workstation, one can then run several VMs, perhaps based around a similar starting OS and cloned. This way, one can have VMs focusing on tasks (document writing, browsing the naughty sites, payroll, etc.) With wise use of snapshots and isolation, if one of the VMs gets compromised, its just a click away from being rolled back to a clean state.
The only issue is getting data between the VMs, say from the payroll VM to the VM with the mail program. However, one can make a virtual hard disk that can be connected and disconnected from machines, perhaps being hooked up to a third, non Windows VM to check for tainted autorun.inf files and other stuff before it gets shuttled to a more security sensitive VM.
This is a lot of work, but compartmentalization and the ability to dump all changes in a filesystem to a known good point will go a long way in security.
This is something I'm wondering. Perhaps the best thing would be for the "Red" machine to be completely rolled back when done using, and have a virtual share mapped for any data that is worth saving.
PGP Desktop has this option. You can share a key and split it among people, where x amount of y pieces are needed to recover the original key, where both x and y are user selectable values.
However, if a key is a top root CA key, you would not be using it on a general purpose computer. You would have the key generated in a HSM and stored there, where someone can perhaps use the key to sign and decrypt stuff, but would have to go to a lot of trouble to get past all the hardware tamper evident stuff in the HSM to access the raw private key material.
Most newer HSM devices I've seen have a way to back up keys generated on the device (usually to USB flash drives), provided at key generation time you set a flag allowing the key to leave the device. If this "allow private key material to leave the HSM" flag isn't explicitly set, you are screwed when it comes to backups, and your best workaround is to create another key with the flag set, then do some cross signing. Depending on task, you might be able to get away with revoking the old key, but sometimes (especially if the old key signed a lot of code certificates), this may be almost impossible.
This lost key should be a lesson to people. Making sure the keys that are in the armored box are backed up can be just as important to security as keeping them in the armored box in the first place. Ideally, consider multiple HSM hardware at multiple locations, including an offline HSM stored in padded packaging that goes in the Iron Mountain tub, as well as the means to access the key inside the box.
It is risky, but there are not many alternatives. A game company can:
Get a license to have their stuff on a console where piracy isn't an issue. This takes a lot of dough to get developer's access to this market. Get an agreement to put titles on Steam. This also is cost prohibitive for smaller game writing companies unless they score a publisher. Go with vigorous DRM which will help their first week or two sales, but will turn off legit users when the bad press mounts up. Go with no DRM, and grumble about the freeloaders.
There is no best solution to this. However one solution that is workable would be to have the game have a CD-key that is checked for multiplayer play over the Internet, and is checked when it comes time to download a patch or added content. This way, single players and LAN play isn't affected, but if people want added content, they will need a valid key. Yes, this can be gotten around, but so can every other system out there.
Another probable solution, especially if first week sales numbers are valuable, is to put in a copy protected CD or activation based DRM system for a month or two on game release, then patch it out similar to how NWN 1 had the CD protection patched out. The downside of this would be the cost of paying the DRM library seller (or running the activation infrastructure in-house) for use of their product for a short time.
The question is more of how much can the PC gaming community can take. First, it was more intrusive DRM, then activation, now its having to be online just to play a single player campaign.
I'm seeing an attitude in the game industry that is an off-putter. Yes, the economy in most of the world stinks, but instead of trying to jumpstart sales by putting out some innovative IP, I see the grip tightening over what stuff comes out. This creates a feedback loop because gamers either will just crack whatever protection something had (patch out DRM, make a server emulator), pirate the game, or just give the game company the finger and go back to playing WoW and not bother buying any works that are less functional than the previous versions.
What this does is create an opportunity for a small game company to take the market by storm by making a quality game that ends up widespread and played everywhere. This is how ID Software (and its predecessor, Apogee) got started. Yes, a lot of copies will be pirated, but a lot of times, pirated copies lead to bought copies. Right now, this market is ignored because of the white-hot iPhone app market, but once that hits saturation (could be six months to a year), people will want to have fun PC games again, and an indie software house could do well in all likelihood.
For new games, the barrier to entry is low, and it is high. It is low because almost anyone can write code, get an Authenticode signing key from MS, get an account with RegNow to handle registrations, then use Tucows or download.com as the main place where customers can download the executable. The barrier to entry is high because users are expecting 3D, theater quality graphics and sound at every turn. The days of writing a generic top-down RPG along the lines of Final Fantasy Legends are long over, unless one is writing an iPhone app. So, an indie publisher will have to deal with that by having gameplay so good it overshadows dated graphics.
The closest solution for this on an enterprise basis would be Windows 7 and BitLocker To Go. Set a policy that USB flash drives are either not accessible, or read-only until they are encrypted with a passphrase. PGP Universal also has this functionality.
This falls under the "never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway" category. With a lot of WAN Internet connections, it is a lot faster to carry a flash drive with your 8GB of data on it, than to download it from remote, especially if someone is often using different machines (student computer lab, for example.)
The advantage of having it drop access to the data after a certain amount of tries is the same reason people use cryptographic tokens -- brute forcing a passphrase becomes a non issue.
There is another feature of the IronKey that isn't mentioned -- encryption on a machine, say at a student computer lab, but without requiring administrative rights to access the data. A lot of schools disallow admin access, and this is required to mount virtual volumes (TrueCrypt, BestCrypt, PGP, etc.) Having software to allow access to the drive that never needs to leave user space is a good thing in these cases.
IronKey does have a market. Especially for students at larger universities where there are people who lurk in the 24 hour computer labs just looking for a USB flash drive to steal. With a stolen USB flash drive, they can either sell the done homework, or if someone has a paper for a popular class that isn't turned in, actually take the word processing document and call it theirs. The downside is that the distinctive metal case does lure thieves, but the user has to figure out a balance. To the user, is the data on the drive worth the price premium, especially if the data can be used by a thief or extortionist? This applies to faculty too. I'm sure there are those who would be more than happy to sell any test or quiz data that was gleaned from a USB flash drive swiped from a faculty lab.
Another use for these USB flash drives is delivering to a customer something extremely confidental (such as TrueCrypt keyfiles or one time pads) that will be used for future communication of large volumes of data. For example, the customer gets the passphase from a rep, while a secure courier drops off the IronKey. This way, the data never crosses the Internet.
Naw, I recommend an AC motor connected to a generator via a short shaft linkage, perhaps some gearing to ensure it spins exactly at 3600 RPM in the US, and 3000 RPM in Europe (60hz and 50hz respectively). Yes, it wastes a good amount of power because it converts electricity to rotational movement and back again... but it is going to be difficult for one side to figure out what the other side is doing. Especially if the secure side then has an online UPS with a decent array of deep cycle batteries.
For even more security, there is always power over the air that Tesla worked on and there have been some advances in.
But, in reality, the only solid defense against this type of attack is to get TEMPEST rated equipment that is shielded from the power plug on with high quality mu metal wrapped around everything.
I can see this technology being able to be used to help with inter-chip communication, perhaps to help with running more tasks in parallel, or locking/unlocking memory segments shared by the CPUs.
The only thing I see that would be a limit is having to mux/demux a lot of signals before they get put on the fiber optic cable. However fiber optic cables have a lot of bandwidth, so this may not be a big issue.
It would be nice if silicon chip lasers could replace most signal circuits on a PC board. Mainly because it would allow positioning of components to allow for better cooling and heat dissipation. Ultimately, if several fiber optic connections can replace the hundreds (going on thousands) of pins needed on a CPU to the motherboard, it would be a great advance in reliability.
Fiber optics on chips isn't new though. I remember talk about the PowerPC 603 having the ability to have this for better SMP communication.
I've seen that misstated multiple times recently. News sources saying that the US government machines got "compromised", then some piece lambasting the US government for being insecure. Apparently, they did not understand the difference between a swarm of hosts flooding a victim machine so it can't take legit requests versus someone breaking into the machine and obtaining data.
In this case, there is almost nothing that can be done to prevent one of these attacks by the victim.
However, to a lot of people a DDoS and a complete pwning are the same thing. A down host is a down host regardless if it were cracked and all drives zeroed out versus a bunch of machines sending bogus requests.
Yes, a DDoS is bad. However, a box that is compromised and rooted is a thousand times worse.
This reminds me of the '90s and MS-DOS viruses. At first, people didn't care because stuff like Brain, et al. were annoying but not malicious. Then came more and more destructive variants. Once BIOSes started getting zapped, people started making sure that they downloaded from a clean source and used AV protection.
Times are similar now. Malware used to be annoying because it was fairly crappy code that bogged down a machine. These days, because malware has matured to the point where a user doesn't even know it is present on a system, they tend not to care. Such as the attitude of "I'll do what I want on my computer, if I get my machine slowed down, Geek Squad will fix it for me". If something malicious software bit them, wiping everything on a widespread basis, it might spur Joe Sixpack into not using IE with all settings set to "Low" because the pr0n sites don't complain that way.
However, having a lot of clueless users get their data zapped this isn't a good thing overall. A lot of them will not do a thing for their own security. Instead, they will beg the lawmakers to do something, and feel good (or more aptly, feel "secure") legislative solutions rarely address international problems. Lots of bad things can happen down this path, from mandated "security" software to be on machines, to efforts to make PCs closed appliances like video game consoles.
The thing is, how are the browser instances connected? If two use the same chunk of the filesystem, a compromised instance can sit watching what is downloaded, and as soon as an executable is copied, and add a payload.
There are a number of race conditions an infected instance can do, from adding a redirect site to bookmarks stored to grabbing session authorization cookies, to altering cached files so when a clean browser instance hits a cache, it picks up an infected object which would compromise the new instance.
It would be great if browsers had a special high security mode where instances would be completely separate, not just address space, but filesystem space, perhaps only allowing access to the bookmark file via a database-like parser thread.
Of course, instanced browsers don't mean that plugins are instanced. It might be that some player may just spawn one executable process to handle all requests to play media, even if one request is from a dodgy ad server doing exploits and another is from a bank.
What I have done sometimes is using VirtualPC and a generic XP VM for Web browsing. VirtualPC may not have the advanced features of heavy snapshotting or clustering, but the functionality it has for storing a change log, and dumping all changes immediately when the VM closes is good enough. Add to this running the Web browser under a limited user in the VM, and this narrows down the attack surface quite a bit. Should malware get on the VM, all it will see on the VM's local network segment is the VirtualPC DHCP server and gateway.
VMs do get cumbersome. Another tool that is useful in the XP toolbox is the old dropmyrights.exe. This venerable utility is great for wrapping a Web browser and having it run as a user, or a restricted user with little access to the Registry.
Of course, there is always the Firefox version from thindownload.com which does not touch the Registry in any way, and writes all changes the app does to a directory under the user (including Registry stuff.) However, even virtualized by app software, something running in a context level can always be of some menace. Also, for enterprise environments, the version from thindownload isn't Authenticode signed, which can be very risky.
For the future of Web browsers, OS makers having functionality (IE7/8's sandbox in Vista, BSD jails, RedHat's app profiles) to allow Web browsers to run in a limited context is a good thing. Since essentially, a Web browser is an OS whose job it is to process untrusted and possibly hostile code from the second it starts up to when the user closes all sessions. However, sandboxing the browser this is only one security tool and can't cover all uses. A compromised browser could be safely contained, but malware could be sitting there to grab a perfectly legit download a user gets, and tamper with it so when the user takes it out of the sandbox, it can do its dirty work. Or, when the user does a bank transaction, act as a MITM and when a user does a small transfer, change the values and destination, empty the bank account, and show the user that their transfer was successful (IBM's ZTIC is a way to help protect against this.)
The battle for desktop (and a good chunk of corporate) security has changed from the OS and IP stack front (ping of deaths, teardrops, and other IP stack attacks are long since been addressed, hardware routers are commonplace, and OS makers have made it quite easy to deny incoming packets at the IP layer with a click of a mouse button), to the Web browser, the tasks used for rendering a page, and the plugins it runs. The Web browser can be extremely secure, but all it takes is one broken plugin to be a weak link, and it can be compromised.
I'm hoping for solar panels that don't require rare metals. Long term, it might trade our dependency on oil for depending in some area that is hostile for something like palladium or platinum.
The best would be something made out of silicon or carbon completely. Perhaps an efficient solar panel made out of silicon coupled with a good lens that might be just the thing that makes solar panels cheap, durable, and efficient enough to reach critical mass.
I also encountered the hardware failure issue on a home machine, and when it stung me, it could have stung me in a big way:
I was using a motherboard and its onboard hardware RAID for some drives in a RAID 5 configuration. It configured, booted, and installed with zero problems. However, after a couple reboots, it gave notice that it was running in degraded mode. Then, on the next reboot, all drives were marked as bad on the controller. All the data on the RAID 5 drive was history. When I did a SMART test on the drives, the drives were healthy without reporting a single issue.
Thankfully, there wasn't anything stored on the drive array that was important, because the machine was still being burned in.
After flipping the drives back to normal SATA drives (as opposed to RAID candidate drives) in the BIOS settings, and using the software RAID functionality in Windows Server 2008, the array has been working (knock on wood) well ever since.
The disadvantage of the software RAID: It appears to take up 20-40% of one CPU core while it does reads and writes for the parity calculation, compared to lower overhead when the hardware dealt with the parity checks. However, with a multi-core machine, this is decently tolerable.
Some motherboards have a high quality onboard RAID controller that completely separates the parity calculations from the CPU. Others use "hardware assisted" RAID, as opposed to doing all the work itself. If a person wants true hardware RAID, consider a SATA RAID card from a known good brand.
As many people have said, RAID is good against hardware failure. However, just like any storage medium, there are many other things that would zap the data, from malware that zero out directory structures, to filesystem corruption. Ultimately, if one wants a top quality backup solution next to a hot remote site or paying $100 per month per TB for renting bits on an offsite cloud, one should consider tape backups, a good rotation and offsite schedule. Of course, consider buying another tape drive of the exact brand and such, testing it, and chucking that (with proper padding) in the Iron Mountain bin so there isn't a panic of finding a usable drive when recovering from a major disaster. Same with the backup program. Finding license keys for whatever software sucks when trying to get production stuff back up to speed.
Don't forget -- controllers also fail even when redundant. I have personally dealt with RAID controllers on a higher end server fail and start writing garbage to an array, making the presence of a failover controller pointless.
They have endpoint protection for Linux actually. From their website, SEP 10 supports:
Linux Operating Systems (32-bit and 64-bit versions)
* Red Hat Enterprise Linux 3.x, 4.x, 5.x
* SuSE Linux Enterprise (server/desktop) 9.x, 10.x
* Novell Open Enterprise Server (OES/OES2)
* VMWare ESX 2.5, 3.x
* Ubuntu 7.x, 8.x
* Debian 4.x
Funny thing is that I have used both this and McAfee (McAfee has had antivirus software for Linux, Solaris, and AIX for more than a decade now.) I used to run the McAfee version at home not because of UNIX based threats, but to nab anything on my samba server that is Windows based.
In businesses, often times a contract has a stipulation that all computers have antivirus software on them. Yes, even the Solaris boxes which are running the large Oracle databases, or the AIX boxes being used for CATIA. So, AV software goes on those machines, not because it does anything other than fire off a scan from a crontab every so often, but because it satisfies that contractual checkbox.
As more security breaches hit the news, having an antivirus software on the UNIX machines will likely become a requirement more often. Even though most UNIX boxes need AV software like a fish needs a bicycle, it's present so management can say that every box on their network is protected.
I have found that Symantec Endpoint Protection does quite well on modern hardware, especially if you get the latest version update which helps with a lot of various CPU-eating bugs. For older hardware, I recommend Avast! which is very lightweight, especially on boxes with 1GB of RAM or less.
For organizations, I would recommend they make sure their antivirus solution is ICSA [1] labs certified. AVG, Avast!, Mcafee, and Symantec/Norton are on this list. Because of this certification, this does well for claiming that a product meets "due diligence" should an audit happen (IANAL, of course.)
However, when you start going from a few PCs to the hundreds, you need to have a way to show from a central console that every PC on your network not just has an antivirus program installed and current, but its configured to abide by contract stipulations, and corporate regulations. This is where Symantec Endpoint Protection is good. Because it is the "corporate" version (where the big hammer of the BSA is a far bigger deterrent to piracy than any activation or subscription methods), SEP doesn't care if a subscription is in date or out of date, it grabs updates and applies them. Come audit time, one can make a nice printout of all the boxes on the corporate LANs, and how they are locked down in a matter of minutes.
Another advantage of SEP is that its installable on servers without requiring a specific "enterprise" version. You msiexec/i the SEP install file, assign the server to a management group (or create a dummy one), run an update, and are done for the most part. SEP is smart enough not to install the more intrusive process scanning stuff on a server, but still will provide filesystem and network protection.
As for the free A/V stuff the Symantec exec states, the key is to consider your threat model on your computer. Someone who has a hardware firewalling router, runs as a limited user (or knows exactly what the UAC dialog is popping up), runs with proper browser security can get by with almost anything, as the A/V program is last ditch protection, rather than having to compensate for an inexperienced user's mistakes. If you are dealing with multiple users in a household, something more full featured such as Norton or SEP would be a good thing. SEP would be more proactive with grabbing infected downloads out of the clutches of the Web browser before they could do damage, as well as catching security holes that should have been patched, but are not.
Usual disclaimers apply. YMMV and IANAL come to mind.
[1]: Of course, ICSA is a subsidiary of Verizon, but they are independent enough that the fact that a product is certified with them is a very good thing to have.
The advantage of the dual link setup is that public key cryptography can be done away with altogether. Public key cryptography as of now is secure, but there are worries about it, from theoretical algorithms that speed up factoring, to very large key sizes and large amounts of computations required for larger keys (Big O for larger key sizes is N^3, so an 8192 bit key would require 64 times as much CPU power as a 2048 bit key.)
Of course, because the two machines negotiate a key over a secure connection, there is no PKI needed to protect against man-in-the-middle attacks. No certificates, CRLs, worries about a CA compromise, or expired keys. The two machines set up a session key via the secure connection by themselves, and then use it over the insecure connection. Barring a machine (or admin) compromise, an attacker would have to either attack the quantum system, or brute force session keys; both very difficult to do. When it comes to security, the simpler the better (ceteris paribus).
If one ran the quantum encrypted backbone on one adapter of machines, and normal Internet stuff on another, perhaps the handshakes and the key exchange for large volume data transfers over SSL or ssh be done via the quantum interface, then the session key negotiated be used over the Ethernet link. This way, should a private key be compromised or broken on a host it would not affect future communications (assuming the security hole is patched and the machine re-secured.)
I can see running these two networks in parallel for a network that spans companies, say for credit card validation from businesses to banks, inter-bank communication, or communication between hospitals. The regular backbone would be used for bulk file transmissions encrypted with a negotiated key via the quantum link, or if a small file needs maximum security, it can be sent along the low bandwidth link.
I think the quote "receded in terms of significance" means that because consoles don't have the illusion of piracy problems that PCs do, and consoles can also bring a lot of additional revenue streams that are not present with PCs (like DRM-ed downloadable content), it means that more bucks on average can be made from the console gamer than the PC gamer.
PCs are not going away anytime soon. In this economy, it becomes harder for someone to justify the cost of a console if they don't have one already, while PCs are virtually everywhere. If a game company can get something playable on the average Mac hardware (I heard a rule of thumb is to get a game working decently on the last model of x86 Macbook running Windows under Boot Camp, so if something runs well on the white/black polycarbonate Macbooks made in early 2008, they have a large market of people they can sell to.)
As for piracy, for every measure on a PC, there is a counter measure. If a company makes a dongle, an emulator is written. A company does CD protection, a patch gets put out. Activation? Will get patched. Forced authentication off a server? Someone will make a client patch and offer private servers. DMCA hammer gets swung, the torrents come from non-WIPO nations. This is why game companies absolutely adore consoles and the total lockdown they bring. The best compromise I have seen to slow down PC game piracy is what Bioware did with NWN1 after the no CD patch, which is to check serials if someone connects to the Internet servers, but allow LAN play (perhaps a serial check can be done here, but this can be beaten by a keygen). Of course, there will be a number of freeloaders, but there will also be a lot of paying customers, and a company should only focus on the customers who shell out the bucks and not fret about pirates [1]. Instead, spend the time and effort into expansions and refining the IP.
Should the big players leave the market (I doubt it even with all the wringing of hands about piracy), then smaller game companies will move in to fill the void. This is similar to how ID was born in the first place with starting in the shareware market. There is always room for good games for the PC because they are not leaving the desks of most of the gamers anytime soon.
[1]: This doesn't mean to not protect one's copyrights and trademarks, but not to worry that there is a large number of pirates out there using the products. If users of pirated copies can't use the multiplayer networks, nor download game patches, they are not consuming much in the way of resources. Plus, it gets word of mouth of a game out, because oftentimes, pirated "demo" copies turn into fully licensed versions.
Unfortunately, this is where OSS is weak. The larger companies (Google, Amazon) can afford the large iron and backend storage stacks [1]. For the uptimes that modern cloud storage has, the equipment costs are tremendous, because the machines that are able to do the large volume I/O over the net not just have to have performance, but be engineered around reliability, and that means large clusters distributed over geographically different regions storing identical data.
I don't really see how an open source solution can compete here, unless it received funding from governments or research institutions. Reliable cloud storage is all about physical hardware.
The only way I can see an OSS cloud appearing is if someone makes a program that would get clients to set aside part of a hard disk. Then, when someone writes to the cloud, the central server encrypts the data, then splits the data among clients assuming that relatively few will be up, and able to be connected to via an application. Ages ago, there was a LAN level utility for the Mac (worked on System 6 and 7) which created a virtual Appleshare drive by using a chunk of hard disk space from all the linked up machines, and using encryption (or obfuscation) to ensure that only the administrator had full access to the share.
Scaling a utility that keeps track of every write, how many splits (including redundant ones) and where would be extremely daunting. It may be doable, but it would not even come close to the performance of a commercial cloud. Reliability is iffish, especially after a long time as participating machines get reinstalled over time, so the central storing program would have to keep shuffling data around. Of course, unless architected right, there is a central point of failure with the machines that assign the bits to the client machines.
Legal issues also apply. A cloud that is completely open will eventually be used for storing information that is highly illegal in some countries. Would someone participating by offering some HDD space be able to be charged with possession, even though they had an encrypted chunk inaccessible to them? This is very hazy legal territory. Some areas of the world could say its like storing a friend's safe full of doobies; its not accessible, but can still be considered possession.
[1]: I'm calling it a stack because there are a number of layers before bits flung into the cloud hit a physical platter, from distribution among sites, to optional encryption, to an accounting system to not just know how much is stored, but how much for how long, then finally passing the objects to a backend database.
That's DES that was used three times in an E-D-E mode (subkey 1 encrypts, subkey 2 decrypts, subkey 3 encrypts). This allows the dedicated DES hardware to be used to give 112 bits (not 168) of security. This was done out of necessity to have a modern keyspace until another cryptographic standard (AES) could be implemented.
Doing the same thing with AES would get far less returns. AES is a fast algorithm, and running AES-128 three times to have the bit width of AES-256 wouldn't increase security as much as people think. It would also be more CPU intensive than one run of AES-256 as well, and there are a lot of tasks AES is used for that are time sensitive. Finally, as of now, AES is still secure, and all doing a triple AES run would do is just burn up needed CPU cycles.
Instead of using AES multiple times, if there is serious concern that AES is weakened, people should consider using a cascade cypher, where they use AES with Serpent, Twofish, or another modern algorithm that supports at least a 128 (preferably 256) bit key, and a 128 bit block size. The algorithms would need to have the same block (not key) size for optimal processing.
From what I recall, if someone cascades three ciphers of 256 bits, they are not really going to get 768 bits of protection, they will get about 258 bits. However, the main advantage of a cipher cascade is that if one of the algorithms has been found to have a serious weakness, the other two will still protect the data, so an attacker will still have to deal with the full 256 bits of one of the algorithms used.
Slashdot Mirror
The problem is that there is no good single solution. Just like there is no one single lock that would secure a building. You have to have multiple backup solutions, with some being onsite for fast rebuilds in case of RAID failure or malware infection, and slower, offline backups that takes a bit to get to, but are insulated from a severe and through attack by a blackhat or malware.
First stage: Consider mirroring of OS partitions, and if your OS/filesystem supports snapshots, have it do those often. One can do this in Windows Server 2003 and 2008 quite easily per volume, Vista is a bit harder, but it does have some snapshot functionality. This layer is for recovering deleted/corrupted files or directories without having to reach for restore media.
Second stage: Have an external drive connected for Time Machine, Vista's file backup, Acronis TrueImage, and set to backup at least nightly. This layer is intended for completely rebuilding a machine due to hardware failure, or to restore files that are not stored as a filesystem snapshot.
Third stage: Have a dedicated backup server, running some network backup program (Retrospect, Backup Exec, Networker, TSM), and make sure the backup server not just is hardened from network attacks because it has all the crown jewels, but the drives are encrypted so its theft would not be catastrophic. One can use EncFS, loopback mounts, TrueCrypt, BitLocker, PGP, or program of choice for this. I leave the data volumes unencrypted for speed, encrypt the boot volume, and use the backup program's encryption, so if someone steals the RAID array, it will be little more than a hardware gain. On the backup server, have a DVD writer available, ISOs of OS media, and a database of CD keys so a machine can be installed and reactivated without having to hunt for the right string of characters.
Fourth stage: Disk to disk to tape. You have a tape drive (or a library) attached to the backup server. This way, machines can back to a RAID array, minimizing the backup window, but you can get backups moved to tape or perhaps external hard disks for safekeeping and offline storage. The advantage of tape is that you can physically set the cartridges read only, so should the backup server get infected, it cannot alter data on the media. Same with tape drives that use WORM functionality like DLTIce. Consider a good tape rotation, and offsiting the tapes. Also, when offsiting a bin of tapes, don't forget to include a DVD with media and license keys for both the OS and the backup program to be able to start restores. Tape is expensive, but there are removable hard disk solutions to mimic the good part of tape usage such as what RDX technology sells (such as write protection).
Fifth stage: Offsite backups. I have had great luck with Mozy, and you can specify it to use a dedicated keyfile for encryption, so even if someone breaks into the Mozy account, without that keyfile, the data is useless to them. Of course, I keep a copy of the keyfile offsite and encrypted with a long passphrase to prevent chicken/egg scenarios.
Sixth stage: Critical files and documents (tax records, legal info) copied to a DVD-R or USB flash drive every quarter or so and stored in a format decodable in any platform. This includes the Mozy keyfiles, the BitLocker recovery keys, ISO images of the TrueCrypt volume recovery disks and header files, PGP keys, and any other cryptographic info. Since gpg files are decodable by almost any OS out there, I use that. This way, should real disaster happen, at least critical records would be recoverable.
Seventh stage: Hard copy printouts of critical documents (payroll, tax records) every six months to year. This even includes source code trees. These are boxed and stuck in storage. This is the extreme of offline copying, but it ensures that data will be around and usable should something like a long nationwide power outage occour (on the order of months to years). This is rather extreme, but it allows a company to go back to paper
The only place where using VMs for projects might not work well are applications (including games) which require Direct X and high performance. VMWare Workstation has some experimental support for DX9, but if one wants to play a game, probably their best bet would be a second drive with an OS that isn't used for anything other than gaming.
This idea of using VMs could make for some interesting security on laptops that have TPM chips:
First, the laptop would be secured with BitLocker. This would provide two things, first, hardware and MBR tamper detection. Someone messes with the laptop while its not attended, it won't boot and ask for the recovery key. Second, BitLocker is transparant once it boots. No need to worry about an additional passphrase (though the recovery key should be kept someplace secure).
The main OS here is mainly used just as an enlighted host for the other VMs. Using Hyper-V or VMWare Workstation, one can then run several VMs, perhaps based around a similar starting OS and cloned. This way, one can have VMs focusing on tasks (document writing, browsing the naughty sites, payroll, etc.) With wise use of snapshots and isolation, if one of the VMs gets compromised, its just a click away from being rolled back to a clean state.
The only issue is getting data between the VMs, say from the payroll VM to the VM with the mail program. However, one can make a virtual hard disk that can be connected and disconnected from machines, perhaps being hooked up to a third, non Windows VM to check for tainted autorun.inf files and other stuff before it gets shuttled to a more security sensitive VM.
This is a lot of work, but compartmentalization and the ability to dump all changes in a filesystem to a known good point will go a long way in security.
This is something I'm wondering. Perhaps the best thing would be for the "Red" machine to be completely rolled back when done using, and have a virtual share mapped for any data that is worth saving.
PGP Desktop has this option. You can share a key and split it among people, where x amount of y pieces are needed to recover the original key, where both x and y are user selectable values.
However, if a key is a top root CA key, you would not be using it on a general purpose computer. You would have the key generated in a HSM and stored there, where someone can perhaps use the key to sign and decrypt stuff, but would have to go to a lot of trouble to get past all the hardware tamper evident stuff in the HSM to access the raw private key material.
Most newer HSM devices I've seen have a way to back up keys generated on the device (usually to USB flash drives), provided at key generation time you set a flag allowing the key to leave the device. If this "allow private key material to leave the HSM" flag isn't explicitly set, you are screwed when it comes to backups, and your best workaround is to create another key with the flag set, then do some cross signing. Depending on task, you might be able to get away with revoking the old key, but sometimes (especially if the old key signed a lot of code certificates), this may be almost impossible.
This lost key should be a lesson to people. Making sure the keys that are in the armored box are backed up can be just as important to security as keeping them in the armored box in the first place. Ideally, consider multiple HSM hardware at multiple locations, including an offline HSM stored in padded packaging that goes in the Iron Mountain tub, as well as the means to access the key inside the box.
It is risky, but there are not many alternatives. A game company can:
Get a license to have their stuff on a console where piracy isn't an issue. This takes a lot of dough to get developer's access to this market.
Get an agreement to put titles on Steam. This also is cost prohibitive for smaller game writing companies unless they score a publisher.
Go with vigorous DRM which will help their first week or two sales, but will turn off legit users when the bad press mounts up.
Go with no DRM, and grumble about the freeloaders.
There is no best solution to this. However one solution that is workable would be to have the game have a CD-key that is checked for multiplayer play over the Internet, and is checked when it comes time to download a patch or added content. This way, single players and LAN play isn't affected, but if people want added content, they will need a valid key. Yes, this can be gotten around, but so can every other system out there.
Another probable solution, especially if first week sales numbers are valuable, is to put in a copy protected CD or activation based DRM system for a month or two on game release, then patch it out similar to how NWN 1 had the CD protection patched out. The downside of this would be the cost of paying the DRM library seller (or running the activation infrastructure in-house) for use of their product for a short time.
The question is more of how much can the PC gaming community can take. First, it was more intrusive DRM, then activation, now its having to be online just to play a single player campaign.
I'm seeing an attitude in the game industry that is an off-putter. Yes, the economy in most of the world stinks, but instead of trying to jumpstart sales by putting out some innovative IP, I see the grip tightening over what stuff comes out. This creates a feedback loop because gamers either will just crack whatever protection something had (patch out DRM, make a server emulator), pirate the game, or just give the game company the finger and go back to playing WoW and not bother buying any works that are less functional than the previous versions.
What this does is create an opportunity for a small game company to take the market by storm by making a quality game that ends up widespread and played everywhere. This is how ID Software (and its predecessor, Apogee) got started. Yes, a lot of copies will be pirated, but a lot of times, pirated copies lead to bought copies. Right now, this market is ignored because of the white-hot iPhone app market, but once that hits saturation (could be six months to a year), people will want to have fun PC games again, and an indie software house could do well in all likelihood.
For new games, the barrier to entry is low, and it is high. It is low because almost anyone can write code, get an Authenticode signing key from MS, get an account with RegNow to handle registrations, then use Tucows or download.com as the main place where customers can download the executable. The barrier to entry is high because users are expecting 3D, theater quality graphics and sound at every turn. The days of writing a generic top-down RPG along the lines of Final Fantasy Legends are long over, unless one is writing an iPhone app. So, an indie publisher will have to deal with that by having gameplay so good it overshadows dated graphics.
The closest solution for this on an enterprise basis would be Windows 7 and BitLocker To Go. Set a policy that USB flash drives are either not accessible, or read-only until they are encrypted with a passphrase. PGP Universal also has this functionality.
This falls under the "never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway" category. With a lot of WAN Internet connections, it is a lot faster to carry a flash drive with your 8GB of data on it, than to download it from remote, especially if someone is often using different machines (student computer lab, for example.)
The advantage of having it drop access to the data after a certain amount of tries is the same reason people use cryptographic tokens -- brute forcing a passphrase becomes a non issue.
There is another feature of the IronKey that isn't mentioned -- encryption on a machine, say at a student computer lab, but without requiring administrative rights to access the data. A lot of schools disallow admin access, and this is required to mount virtual volumes (TrueCrypt, BestCrypt, PGP, etc.) Having software to allow access to the drive that never needs to leave user space is a good thing in these cases.
IronKey does have a market. Especially for students at larger universities where there are people who lurk in the 24 hour computer labs just looking for a USB flash drive to steal. With a stolen USB flash drive, they can either sell the done homework, or if someone has a paper for a popular class that isn't turned in, actually take the word processing document and call it theirs. The downside is that the distinctive metal case does lure thieves, but the user has to figure out a balance. To the user, is the data on the drive worth the price premium, especially if the data can be used by a thief or extortionist? This applies to faculty too. I'm sure there are those who would be more than happy to sell any test or quiz data that was gleaned from a USB flash drive swiped from a faculty lab.
Another use for these USB flash drives is delivering to a customer something extremely confidental (such as TrueCrypt keyfiles or one time pads) that will be used for future communication of large volumes of data. For example, the customer gets the passphase from a rep, while a secure courier drops off the IronKey. This way, the data never crosses the Internet.
Naw, I recommend an AC motor connected to a generator via a short shaft linkage, perhaps some gearing to ensure it spins exactly at 3600 RPM in the US, and 3000 RPM in Europe (60hz and 50hz respectively). Yes, it wastes a good amount of power because it converts electricity to rotational movement and back again... but it is going to be difficult for one side to figure out what the other side is doing. Especially if the secure side then has an online UPS with a decent array of deep cycle batteries.
For even more security, there is always power over the air that Tesla worked on and there have been some advances in.
But, in reality, the only solid defense against this type of attack is to get TEMPEST rated equipment that is shielded from the power plug on with high quality mu metal wrapped around everything.
I can see this technology being able to be used to help with inter-chip communication, perhaps to help with running more tasks in parallel, or locking/unlocking memory segments shared by the CPUs.
The only thing I see that would be a limit is having to mux/demux a lot of signals before they get put on the fiber optic cable. However fiber optic cables have a lot of bandwidth, so this may not be a big issue.
It would be nice if silicon chip lasers could replace most signal circuits on a PC board. Mainly because it would allow positioning of components to allow for better cooling and heat dissipation. Ultimately, if several fiber optic connections can replace the hundreds (going on thousands) of pins needed on a CPU to the motherboard, it would be a great advance in reliability.
Fiber optics on chips isn't new though. I remember talk about the PowerPC 603 having the ability to have this for better SMP communication.
I've seen that misstated multiple times recently. News sources saying that the US government machines got "compromised", then some piece lambasting the US government for being insecure. Apparently, they did not understand the difference between a swarm of hosts flooding a victim machine so it can't take legit requests versus someone breaking into the machine and obtaining data.
In this case, there is almost nothing that can be done to prevent one of these attacks by the victim.
However, to a lot of people a DDoS and a complete pwning are the same thing. A down host is a down host regardless if it were cracked and all drives zeroed out versus a bunch of machines sending bogus requests.
Yes, a DDoS is bad. However, a box that is compromised and rooted is a thousand times worse.
This reminds me of the '90s and MS-DOS viruses. At first, people didn't care because stuff like Brain, et al. were annoying but not malicious. Then came more and more destructive variants. Once BIOSes started getting zapped, people started making sure that they downloaded from a clean source and used AV protection.
Times are similar now. Malware used to be annoying because it was fairly crappy code that bogged down a machine. These days, because malware has matured to the point where a user doesn't even know it is present on a system, they tend not to care. Such as the attitude of "I'll do what I want on my computer, if I get my machine slowed down, Geek Squad will fix it for me". If something malicious software bit them, wiping everything on a widespread basis, it might spur Joe Sixpack into not using IE with all settings set to "Low" because the pr0n sites don't complain that way.
However, having a lot of clueless users get their data zapped this isn't a good thing overall. A lot of them will not do a thing for their own security. Instead, they will beg the lawmakers to do something, and feel good (or more aptly, feel "secure") legislative solutions rarely address international problems. Lots of bad things can happen down this path, from mandated "security" software to be on machines, to efforts to make PCs closed appliances like video game consoles.
The thing is, how are the browser instances connected? If two use the same chunk of the filesystem, a compromised instance can sit watching what is downloaded, and as soon as an executable is copied, and add a payload.
There are a number of race conditions an infected instance can do, from adding a redirect site to bookmarks stored to grabbing session authorization cookies, to altering cached files so when a clean browser instance hits a cache, it picks up an infected object which would compromise the new instance.
It would be great if browsers had a special high security mode where instances would be completely separate, not just address space, but filesystem space, perhaps only allowing access to the bookmark file via a database-like parser thread.
Of course, instanced browsers don't mean that plugins are instanced. It might be that some player may just spawn one executable process to handle all requests to play media, even if one request is from a dodgy ad server doing exploits and another is from a bank.
What I have done sometimes is using VirtualPC and a generic XP VM for Web browsing. VirtualPC may not have the advanced features of heavy snapshotting or clustering, but the functionality it has for storing a change log, and dumping all changes immediately when the VM closes is good enough. Add to this running the Web browser under a limited user in the VM, and this narrows down the attack surface quite a bit. Should malware get on the VM, all it will see on the VM's local network segment is the VirtualPC DHCP server and gateway.
VMs do get cumbersome. Another tool that is useful in the XP toolbox is the old dropmyrights.exe. This venerable utility is great for wrapping a Web browser and having it run as a user, or a restricted user with little access to the Registry.
Of course, there is always the Firefox version from thindownload.com which does not touch the Registry in any way, and writes all changes the app does to a directory under the user (including Registry stuff.) However, even virtualized by app software, something running in a context level can always be of some menace. Also, for enterprise environments, the version from thindownload isn't Authenticode signed, which can be very risky.
For the future of Web browsers, OS makers having functionality (IE7/8's sandbox in Vista, BSD jails, RedHat's app profiles) to allow Web browsers to run in a limited context is a good thing. Since essentially, a Web browser is an OS whose job it is to process untrusted and possibly hostile code from the second it starts up to when the user closes all sessions. However, sandboxing the browser this is only one security tool and can't cover all uses. A compromised browser could be safely contained, but malware could be sitting there to grab a perfectly legit download a user gets, and tamper with it so when the user takes it out of the sandbox, it can do its dirty work. Or, when the user does a bank transaction, act as a MITM and when a user does a small transfer, change the values and destination, empty the bank account, and show the user that their transfer was successful (IBM's ZTIC is a way to help protect against this.)
The battle for desktop (and a good chunk of corporate) security has changed from the OS and IP stack front (ping of deaths, teardrops, and other IP stack attacks are long since been addressed, hardware routers are commonplace, and OS makers have made it quite easy to deny incoming packets at the IP layer with a click of a mouse button), to the Web browser, the tasks used for rendering a page, and the plugins it runs. The Web browser can be extremely secure, but all it takes is one broken plugin to be a weak link, and it can be compromised.
I'm hoping for solar panels that don't require rare metals. Long term, it might trade our dependency on oil for depending in some area that is hostile for something like palladium or platinum.
The best would be something made out of silicon or carbon completely. Perhaps an efficient solar panel made out of silicon coupled with a good lens that might be just the thing that makes solar panels cheap, durable, and efficient enough to reach critical mass.
I also encountered the hardware failure issue on a home machine, and when it stung me, it could have stung me in a big way:
I was using a motherboard and its onboard hardware RAID for some drives in a RAID 5 configuration. It configured, booted, and installed with zero problems. However, after a couple reboots, it gave notice that it was running in degraded mode. Then, on the next reboot, all drives were marked as bad on the controller. All the data on the RAID 5 drive was history. When I did a SMART test on the drives, the drives were healthy without reporting a single issue.
Thankfully, there wasn't anything stored on the drive array that was important, because the machine was still being burned in.
After flipping the drives back to normal SATA drives (as opposed to RAID candidate drives) in the BIOS settings, and using the software RAID functionality in Windows Server 2008, the array has been working (knock on wood) well ever since.
The disadvantage of the software RAID: It appears to take up 20-40% of one CPU core while it does reads and writes for the parity calculation, compared to lower overhead when the hardware dealt with the parity checks. However, with a multi-core machine, this is decently tolerable.
Some motherboards have a high quality onboard RAID controller that completely separates the parity calculations from the CPU. Others use "hardware assisted" RAID, as opposed to doing all the work itself. If a person wants true hardware RAID, consider a SATA RAID card from a known good brand.
As many people have said, RAID is good against hardware failure. However, just like any storage medium, there are many other things that would zap the data, from malware that zero out directory structures, to filesystem corruption. Ultimately, if one wants a top quality backup solution next to a hot remote site or paying $100 per month per TB for renting bits on an offsite cloud, one should consider tape backups, a good rotation and offsite schedule. Of course, consider buying another tape drive of the exact brand and such, testing it, and chucking that (with proper padding) in the Iron Mountain bin so there isn't a panic of finding a usable drive when recovering from a major disaster. Same with the backup program. Finding license keys for whatever software sucks when trying to get production stuff back up to speed.
Don't forget -- controllers also fail even when redundant. I have personally dealt with RAID controllers on a higher end server fail and start writing garbage to an array, making the presence of a failover controller pointless.
They have endpoint protection for Linux actually. From their website, SEP 10 supports:
Linux Operating Systems (32-bit and 64-bit versions)
* Red Hat Enterprise Linux 3.x, 4.x, 5.x
* SuSE Linux Enterprise (server/desktop) 9.x, 10.x
* Novell Open Enterprise Server (OES/OES2)
* VMWare ESX 2.5, 3.x
* Ubuntu 7.x, 8.x
* Debian 4.x
Funny thing is that I have used both this and McAfee (McAfee has had antivirus software for Linux, Solaris, and AIX for more than a decade now.) I used to run the McAfee version at home not because of UNIX based threats, but to nab anything on my samba server that is Windows based.
In businesses, often times a contract has a stipulation that all computers have antivirus software on them. Yes, even the Solaris boxes which are running the large Oracle databases, or the AIX boxes being used for CATIA. So, AV software goes on those machines, not because it does anything other than fire off a scan from a crontab every so often, but because it satisfies that contractual checkbox.
As more security breaches hit the news, having an antivirus software on the UNIX machines will likely become a requirement more often. Even though most UNIX boxes need AV software like a fish needs a bicycle, it's present so management can say that every box on their network is protected.
I'm going to be a devil's advocate here:
I have found that Symantec Endpoint Protection does quite well on modern hardware, especially if you get the latest version update which helps with a lot of various CPU-eating bugs. For older hardware, I recommend Avast! which is very lightweight, especially on boxes with 1GB of RAM or less.
For organizations, I would recommend they make sure their antivirus solution is ICSA [1] labs certified. AVG, Avast!, Mcafee, and Symantec/Norton are on this list. Because of this certification, this does well for claiming that a product meets "due diligence" should an audit happen (IANAL, of course.)
However, when you start going from a few PCs to the hundreds, you need to have a way to show from a central console that every PC on your network not just has an antivirus program installed and current, but its configured to abide by contract stipulations, and corporate regulations. This is where Symantec Endpoint Protection is good. Because it is the "corporate" version (where the big hammer of the BSA is a far bigger deterrent to piracy than any activation or subscription methods), SEP doesn't care if a subscription is in date or out of date, it grabs updates and applies them. Come audit time, one can make a nice printout of all the boxes on the corporate LANs, and how they are locked down in a matter of minutes.
Another advantage of SEP is that its installable on servers without requiring a specific "enterprise" version. You msiexec /i the SEP install file, assign the server to a management group (or create a dummy one), run an update, and are done for the most part. SEP is smart enough not to install the more intrusive process scanning stuff on a server, but still will provide filesystem and network protection.
As for the free A/V stuff the Symantec exec states, the key is to consider your threat model on your computer. Someone who has a hardware firewalling router, runs as a limited user (or knows exactly what the UAC dialog is popping up), runs with proper browser security can get by with almost anything, as the A/V program is last ditch protection, rather than having to compensate for an inexperienced user's mistakes. If you are dealing with multiple users in a household, something more full featured such as Norton or SEP would be a good thing. SEP would be more proactive with grabbing infected downloads out of the clutches of the Web browser before they could do damage, as well as catching security holes that should have been patched, but are not.
Usual disclaimers apply. YMMV and IANAL come to mind.
[1]: Of course, ICSA is a subsidiary of Verizon, but they are independent enough that the fact that a product is certified with them is a very good thing to have.
The advantage of the dual link setup is that public key cryptography can be done away with altogether. Public key cryptography as of now is secure, but there are worries about it, from theoretical algorithms that speed up factoring, to very large key sizes and large amounts of computations required for larger keys (Big O for larger key sizes is N^3, so an 8192 bit key would require 64 times as much CPU power as a 2048 bit key.)
Of course, because the two machines negotiate a key over a secure connection, there is no PKI needed to protect against man-in-the-middle attacks. No certificates, CRLs, worries about a CA compromise, or expired keys. The two machines set up a session key via the secure connection by themselves, and then use it over the insecure connection. Barring a machine (or admin) compromise, an attacker would have to either attack the quantum system, or brute force session keys; both very difficult to do. When it comes to security, the simpler the better (ceteris paribus).
If one ran the quantum encrypted backbone on one adapter of machines, and normal Internet stuff on another, perhaps the handshakes and the key exchange for large volume data transfers over SSL or ssh be done via the quantum interface, then the session key negotiated be used over the Ethernet link. This way, should a private key be compromised or broken on a host it would not affect future communications (assuming the security hole is patched and the machine re-secured.)
I can see running these two networks in parallel for a network that spans companies, say for credit card validation from businesses to banks, inter-bank communication, or communication between hospitals. The regular backbone would be used for bulk file transmissions encrypted with a negotiated key via the quantum link, or if a small file needs maximum security, it can be sent along the low bandwidth link.
I think the quote "receded in terms of significance" means that because consoles don't have the illusion of piracy problems that PCs do, and consoles can also bring a lot of additional revenue streams that are not present with PCs (like DRM-ed downloadable content), it means that more bucks on average can be made from the console gamer than the PC gamer.
PCs are not going away anytime soon. In this economy, it becomes harder for someone to justify the cost of a console if they don't have one already, while PCs are virtually everywhere. If a game company can get something playable on the average Mac hardware (I heard a rule of thumb is to get a game working decently on the last model of x86 Macbook running Windows under Boot Camp, so if something runs well on the white/black polycarbonate Macbooks made in early 2008, they have a large market of people they can sell to.)
As for piracy, for every measure on a PC, there is a counter measure. If a company makes a dongle, an emulator is written. A company does CD protection, a patch gets put out. Activation? Will get patched. Forced authentication off a server? Someone will make a client patch and offer private servers. DMCA hammer gets swung, the torrents come from non-WIPO nations. This is why game companies absolutely adore consoles and the total lockdown they bring. The best compromise I have seen to slow down PC game piracy is what Bioware did with NWN1 after the no CD patch, which is to check serials if someone connects to the Internet servers, but allow LAN play (perhaps a serial check can be done here, but this can be beaten by a keygen). Of course, there will be a number of freeloaders, but there will also be a lot of paying customers, and a company should only focus on the customers who shell out the bucks and not fret about pirates [1]. Instead, spend the time and effort into expansions and refining the IP.
Should the big players leave the market (I doubt it even with all the wringing of hands about piracy), then smaller game companies will move in to fill the void. This is similar to how ID was born in the first place with starting in the shareware market. There is always room for good games for the PC because they are not leaving the desks of most of the gamers anytime soon.
[1]: This doesn't mean to not protect one's copyrights and trademarks, but not to worry that there is a large number of pirates out there using the products. If users of pirated copies can't use the multiplayer networks, nor download game patches, they are not consuming much in the way of resources. Plus, it gets word of mouth of a game out, because oftentimes, pirated "demo" copies turn into fully licensed versions.
Unfortunately, this is where OSS is weak. The larger companies (Google, Amazon) can afford the large iron and backend storage stacks [1]. For the uptimes that modern cloud storage has, the equipment costs are tremendous, because the machines that are able to do the large volume I/O over the net not just have to have performance, but be engineered around reliability, and that means large clusters distributed over geographically different regions storing identical data.
I don't really see how an open source solution can compete here, unless it received funding from governments or research institutions. Reliable cloud storage is all about physical hardware.
The only way I can see an OSS cloud appearing is if someone makes a program that would get clients to set aside part of a hard disk. Then, when someone writes to the cloud, the central server encrypts the data, then splits the data among clients assuming that relatively few will be up, and able to be connected to via an application. Ages ago, there was a LAN level utility for the Mac (worked on System 6 and 7) which created a virtual Appleshare drive by using a chunk of hard disk space from all the linked up machines, and using encryption (or obfuscation) to ensure that only the administrator had full access to the share.
Scaling a utility that keeps track of every write, how many splits (including redundant ones) and where would be extremely daunting. It may be doable, but it would not even come close to the performance of a commercial cloud. Reliability is iffish, especially after a long time as participating machines get reinstalled over time, so the central storing program would have to keep shuffling data around. Of course, unless architected right, there is a central point of failure with the machines that assign the bits to the client machines.
Legal issues also apply. A cloud that is completely open will eventually be used for storing information that is highly illegal in some countries. Would someone participating by offering some HDD space be able to be charged with possession, even though they had an encrypted chunk inaccessible to them? This is very hazy legal territory. Some areas of the world could say its like storing a friend's safe full of doobies; its not accessible, but can still be considered possession.
[1]: I'm calling it a stack because there are a number of layers before bits flung into the cloud hit a physical platter, from distribution among sites, to optional encryption, to an accounting system to not just know how much is stored, but how much for how long, then finally passing the objects to a backend database.
That's DES that was used three times in an E-D-E mode (subkey 1 encrypts, subkey 2 decrypts, subkey 3 encrypts). This allows the dedicated DES hardware to be used to give 112 bits (not 168) of security. This was done out of necessity to have a modern keyspace until another cryptographic standard (AES) could be implemented.
Doing the same thing with AES would get far less returns. AES is a fast algorithm, and running AES-128 three times to have the bit width of AES-256 wouldn't increase security as much as people think. It would also be more CPU intensive than one run of AES-256 as well, and there are a lot of tasks AES is used for that are time sensitive. Finally, as of now, AES is still secure, and all doing a triple AES run would do is just burn up needed CPU cycles.
Instead of using AES multiple times, if there is serious concern that AES is weakened, people should consider using a cascade cypher, where they use AES with Serpent, Twofish, or another modern algorithm that supports at least a 128 (preferably 256) bit key, and a 128 bit block size. The algorithms would need to have the same block (not key) size for optimal processing.
From what I recall, if someone cascades three ciphers of 256 bits, they are not really going to get 768 bits of protection, they will get about 258 bits. However, the main advantage of a cipher cascade is that if one of the algorithms has been found to have a serious weakness, the other two will still protect the data, so an attacker will still have to deal with the full 256 bits of one of the algorithms used.