DRM isn't the right term here. DRM is for locking away content. Instead, what is needed is trusted computing. This is a double edge sword, on one hand, it can be used for making closed appliances like consoles. On the other hand, it can ensure that the contents of a stolen laptop are not accessible even to an intruder who manages to briefly gain access to install a bogus MBR.
For a voting machine, the best way would be to have an open source OS [1], a TPM, and a boot path that would not allow decryption of the root filesystem or any other filesystem containing data if the kernel, MBR, BIOS, or boot sector has been modified. Of course someone can attack the TPM chip, but this requires access to a chip fab and James Bond style tech, not just someone with a USB flash drive and a screwdriver.
Maybe Infineon and the Trusted Computing Group could work on a specification designed with open source operating systems in mind so transparency is maintained as well as security.
[1]: OSS operating system of choice. This could be Linux, BSD, or any other operating system with the source code available for study and runnable in a VM.
Darknets are bandied about from time to time, but their traffic has to cross the Internet in some form or another, because rogue links are just not practical. All it would take is some smart QoS programming to drop any unknown encrypted traffic, and darknets will be relegated to the same status as pirate broadcast radio; doable in some small areas, but not on any real basis. One can play cat and mouse with ports, but darknet traffic would have an obvious signature -- lots of volume, and connectionless. This is easy for any SPF to spot and either log (giving the originator a strike), or dynamically throttle/block.
You might not want that. Laws or treaties can be enacted to force hardware DRM stacks built into every computer (think the PS3), and NAC like functionality on routers and gateways to ensure that machines that connect onto the Internet have such chips that would tag each packet with individual PC metadata (which is easily traced.)
Obligatory car analogy: Look how some states' lawmakers want to install GPS monitors on every vehicle in their borders. Already, any car made in the past decade has an EDR which has a log in a crash of what speed the user was going, brakes applied, and such. 90 years ago, there were no tracking systems for cars, and people didn't think of it. Computers are at the same place.
Maybe FB and Myspace need to move to a different business model, perhaps something up front.
Here is something I'd like to see. A social network that would cost up front something a month. I pay $3 a month to last.fm just so I don't have to bother with ads, so perhaps something around that. A small fee also will slow down spammers who create dummy accounts, because they either have to cough up cash, or start committing credit card fraud in order to continue.
Then, a chunk of the incoming revenue is given to the app writers. If a lot of people play a certain program, the app writer gets a fatter check from the social network. This way, a good programmer could write something and get paid for it without having to resort to trying to sneak $10/month shenanigans into their app.
Of course, advertising revenue can come in too, perhaps offer a two tiered system, free accounts with the usual crapola Flash ads, and paid accounts which don't inflict such stuff on their users.
I started using FB the same reason I created accounts on MySpace and Twitter. Prospective employers want that info, and think that you are behind the times or a Luddite if you don't have it. This was told to my face in a couple interviews I've had.
So, I created a dummy MySpace account that has nothing on it, and only bother logging on to check out bands. My Twitter account has no tweets from me, and it follows a lot of major brands in the industry (IBM, EMC, Microsoft, SOE, Cisco, etc.) FB, I actually use and have some friends there and use it as a messaging source, as well as a way to keep up on a couple events going on.
Maybe this is a pipe dream, but I'd like to see a social networking website where every object (post, movie, file) was considered an object, and each object had security ACLs, similar to how every filesystem object. So, if I want to allow everyone to view something, I'd add the everyone ACL which adds their public key to the object. I'd also have ACLs that are for denying access, so I can explicitly prevent people (or groups) from seeing an entry regardless if they are a friend or not.
This was because Hushmail was forced to either allow the Interpol (which has clout in Ireland and other places Hushmail has their servers) to read what the server decrypted via the Javascript client, or likely face shutdown for not cooperating.
There is absolutely nothing Hushmail's developers could have done once the judge in their area handed the search warrent papers. I still highly recommend using the service, not just for E-mail, but a decent place to store some documents offsite.
Even better, either use a utility like KeePass or roll dice and use Diceware's password generation to make a 64 bit passphrase. Essentially, you really don't need to remember it like you do your router password. Then save the passphrase to a USB flash drive. After pasting it into your router, take the USB flash drive from wireless box to wireless box, copy and paste it in their configs, then either encrypt the usb flash drive key file, or merely store it in a secure place.
This way, an attacker isn't dealing with a 10 character passphrase (might be tough), nor a 20 character passphrase (virtually uncrackable), but more than the 256 bits used in AES. With using a passphrase that has upper/lower case, numbers, and symbols, and all 63 characters (the maximum length passphrase in WPA2-AES), now the door is stronger than the wall.
This is more of a matter of peace of mind, but it also doesn't hurt to change the AES key every so often. I like changing the WPA2 keys out every three to six months, or when I remove a machine from the network to be safe.
Of course, the best security is having a RADIUS server that uses smart cards, and a WAP that can authenticate people from that. This way, for someone to get access, they would have to get physical possession of a cryptographic token, and either know the passphrase, or guess it before the token permanently blocks access.
After you have your WPA2 key done right, you don't need to bother with hiding your SSID (doesn't protect against anything), and you can use an authorized MAC list if you want, but it really doesn't provide that much security.
I had a machine with an nVidia chipset with this semi hardware firewall functionality. At first, it worked quite well, and it supposed some pretty detailed access lists (no outgoing port 25), but after a couple patches, it didn't seem to work right, so after a reinstall due to unrelated issues, I didn't bother installing the nForce drivers.
Overall, I like the idea of having the onboard NIC have router functionality in hardware so packets can be denied and/or filtered before they ever touch the OS. However, I'm sure this functionality will bring substantional added cost, not for both the chips to run a router (CPU, RAM and some storage), but standardized drivers so any OS can easily add/subtract access lists. Of course, the firmware for the NIC interface would have to have its own signing and validation capabilities so malware that roots the main machine can't just quietly flash the NIC and leave an firmware based botnet client. This would be a nice option in premium motherboards though, where one doesn't have to worry about cutting every penny.
You hit upon something here. There are a lot of IT related fields. One can be a sysadmin, a DBA, an admin watching over developer projects, an architect who designs infrastructure, the network admin who sets up the core/edge structure, the implementers who implement, the security auditor, the corporate compliance people, etc.
I wonder if people might be better off changing their IT field, rather than leaving the industry completely and starting from ground zero. For example, changing from a sysadmin specialty to a DBA would require a lot less retooling than changing completely out of IT and not having any common skills.
That is the issue right there: There is no good archival medium for typical users. Perhaps if you get the CD-Rs touted to have a 100 year lifespan and store those vertically in a climate controlled environment, you might have the best luck, but in reality, your best bet is storing the data in multiple archive formats and on multiple types of media. For example, a tar achive, a zip archive, and a winRAR archive with recovery records, then storing those files on a hard disk, burned to multiple CDs, stored on cloud storage, etc.
The only medium I know which would have a truly long shelf life would be printing stuff out on acid free paper in black and white. However, something that can come close would be how one of the old IBM mainframes used to store WORM data. It had a roll of unexposed black and white film (same as what is used in cameras). Then, once the roll was "written" to by exposing it, it would be automatically developed, washed, then fixed, and moved to a library for permanent retrival of the bits. This likely could last a long while, assuming a safe environment, and no chemical issues with the plastic that would cause degradation.
Most operating systems also support hybrid hard disks. I haven't seen many ReadyDrive drives, but I'm sure if there is a market impetus for them, drive makers will happily tack on some flash memory and sell them.
I see hard disk capacity increases slowing down, but in order to remain competitive, HDD makers will start adding more useful features, such as hardware based disk encryption, additional steps for data integrity (multiple heads, multiple "drive-lets" for one drive that has two mirrors with separate platters/heads, more RAM for cache, etc.)
There is one big advantage that HDD makers have: They can add flash storage to their offerings with relative ease, while the other way around is difficult to do for chipmakers. I can see not just hybrid drives, but drives that appear to an OS as multiple volumes. For example, a drive that has 16 to 64 gigs of flash storage for static binaries (OS files), and 2-4 TB of spinning storage for the rest of the data.
HDD makers also have a lot more room to play with than a SSD company, so they can add special features on a drive just for certain tasks, be it enterprise RAID (and ensuring the drives stay in sync), A/V uses (to ensure streaming), encryption co-processers to have enterprise level encryption key management, and so on.
The TPM really doesn't actively encrypt. It never is an active part of the boot process. All it does it get reset on boot, get cryptographic hashes passed to it periodically, then either unseal the key or give the middle finger for the request.. In theory, it could be used to check if a machine was tampered with by asking for the sealed key, and if the TPM wouldn't give it up on boot, then print out that something, somewhere, along the boot path got modified.
However, without encryption of vital data to prevent the booting from completing no matter how bongoed the boot loader and kernel end up, an attacker could just have the bootloader say that the machine always passes the test.
If you want as minimal encryption as possible, you likely are best served by having / encrypted, so the boot process would continue to the point of passing code, then the moment of truth would be if the machine gets to a multi user mode, versus hanging during the init process and asking for the filesystem's recovery key.
When configuring BitLocker to encrypt, unless you do it from the manage-bde utility (a.wsf script in Vista/Windows Server 2008, and an executable in Windows 7/Windows Server 2008 R2), BitLocker will demand that you save a copy of the volume recovery key to non encrypted media. I personally save it to a mounted TrueCrypt volume on a removable drive, and in a password manager on a non connected PDA. This way, should the TPM not work the way it should, all it takes is opening my PDA, typing in the code, getting into Windows, and disabling the TPM key protector until I find out why the TPM went on vacation.
Also, this is a Windows solution. It would be nice to see RedHat and other distro makers use LUKS and a TPM to have similar functionality, but as of now, there are some projects in alpha that one can look at.
This is definitely an itch that someone should scratch on Linux/BSD/OS X, and other places. It would help security of Linux distros immensely. The TPM 1.2 spec is a standard that requires no drivers either.
The TPM is essentially a smart card. It stores the decryption key until asked for it, and the values match. (Technically this is a bit more complicated because on bootup the TPM state is reset, and each part of the boot process scans the next part, passes the cryptographic hash to the TPM, and the TPM then hashes the hold and new parts for a value, and this process of adding and rehashing repeats until the TPM is asked for the key.)
If someone yanks the TPM (some PC motherboards have the chip on a daughter card), then there is no usable key to use for decryption (barring access to recovery media, rubber hoses, or another way to find the key).
Most of the HP business class subnotebooks (HP EliteBook 2730p is one, there are others) have TPM functionality built in. Not all have the functionality built in, and in general, you will be paying a business class price for the security.
It is worth it though. Mainly because you can just set BitLocker (making sure the recovery key is stored somewhere safe) and essentially forget you have hard disk encryption present.
Not just BitLocker works with TPM chips for security software. I know that PGP's WDE product works as well, and for some people that don't want to run Vista or Windows 7, they can get similar protection from tampering by using PGP and the onboard TPM.
If physical security on TPM chips even becomes more than a slight issue, most likely what will happen is that the TPM functionality will move from today's existing chip that doesn't have physical protection, to chips which are epoxy potted onto motherboards (like any video chips that deal with Blu-Ray. The spec requires the maker to drop a blob on epoxy on them to prevent reverse engineering). For high security, I'm sure that the TPM and critical parts of the machine's BIOS will be moved into a metal security container with epoxy potting, as well as multiple tamper mechanisms that will zero out the contents should the case be breached, similar to how smart cards and PCI based key storage modules work today.
FDE has been around since the days of Macs and FWB Hard Disk Toolkit doing a modified (2 rounds IIRC) version of DES on any external hard disks (or Casady and Greene's A. M. E. doing a full DES on disks). It does have a performance it, but from what I've seen (and I've been using WDE in many platforms for a long time), the hit is not an issue with almost all FDE types of programs.
Encryption is a tradeoff. Yes, you lose reliability. However, if you have a decent backup mechanism (and you should regardless of the presence of encryption), the reliability loss isn't much, assuming you remember your password or keep your keyfiles safe.
The last assertion of being easier to break into encrypted data doesn't make sense. I can see people installing a FDE utility then assuming they are safe from all attacks (including ones via remote). If a person is concerned about data, perhaps it might be wise to install TrueCrypt in addition to the FDE security to only mount sensitive files when used and dismount them immediately. This way, should the laptop be seized while on and the memory dumped, an attacker would not have access to the whole filesystem. Similar functionality can be accomplished with multiple users on Windows and EFS.
Oh, the chosen plaintext attack would be a problem if people kept using 64 bit blocks and lame implementations of encryption like ECB. However, with modern algorithms that use a bigger blocksize and a more advanced diffusion protocol which uses a different subkey per sector, an attacker can know all they want to about plaintext, but it will not help them discern the key. The TrueCrypt manual has a good section on this.
Windows 7 is different from Vista in the way businesses and enterprises use it. Vista had two editions that were activated via an internal KMS system (very important when you have thousands of PCs and do not want them touching the Internet for activation). Windows 7 has only one edition that has this functionality, the Enterprise edition. This is available via volume license key agreements. Other than the MAK/KMS model of activation, this edition is the exact same as Ultimate which has BitLocker, BranchCache, and the other items.
So, if a company is using a volume license of Windows 7, they will have access to BitLocker functionality. Server-wise, Windows Server 2008 and Windows Server 2008 R2 both have BitLocker functionality built in.
This way, if a corporation that is running Windows 7 orders a bunch of laptops, they would be fools not to order ones with TPM chips because their OS will easily support this functionality. If they have an Active Directory infrastructure and no existing encryption product (PGP, PointSec), getting BitLocker deployed enterprise wide wouldn't be too difficult with AD holding recovery keys to machines.
I'm glad Microsoft did this. No worry if a company has Business or Enterprise editions for features (like the issues with Vista). Now, if a company has a VLK and uses a key management server for internal activations [1], they have BitLocker available with W7.
[1]: I'm not a fan of activation at all. Personally, my wish is they would have gone back to how XP VLK editions handled this. Businesses are not going to be pirating Windows because the BSA will come for a visit. Pirates will crack any activation. So, there is no real antipiracy benefit to Microsoft in forcing businesses to have an activation infrastructure.
Be careful on saying an attack may not be used widely. Virtually these exact words were said in the late 1990s about ssh and only paranoids having to worry about packet sniffers and session hijackers.
Now, ISPs have appliances whose job it is to insert ads in unencrypted HTTP transfers and transparent Web proxies are fairly easy to set up by anyone knowledgeable. Any business class router supports packet logging, so anywhere between your machine and the host you are connecting to can record every single packet from the SYN to the final ACK.
As of now, the "evil maid" attack may seem farfetched, but in reality, there are many ways to separate an exec from his or her laptop without them getting alarmed. One of those can be done at any border checkpoint where the laptop is taken to be "further inspected" while the exec is being strip searched. All it would take would be a simple bootup from a USB flash drive that scans for popular encryption program headers (TrueCrypt, PGP, PointSec) and some code inserted to save the preboot authentication passphrase somewhere safe for later. This wouldn't take much technological knowledge on the end user side, because all they do is jam the flash drive into a port, tell the laptop to boot from the drive, and then turn the laptop back off. Should the laptop have locked or no USB ports, the drive itself can be removed from the laptop and put into a machine that would do similar functionality (detect encryption, modify the bootloader).
After this is done and the person stays in the country a bit, the laptop can be quietly imaged by outgoing customs or airport security, or just outright seized by security.
The best BitLocker protection is a combination of PIN + TPM + USB flash drive. This way, if a thief rips off your laptop, but you have your USB flash drive with you (either in your wallet, around the neck, or on a keychain), you are pretty much assured that they will not have access to data, no matter what they try.
For additional protection since Windows 7 has been released to everyone, perhaps consider BitLocker To Go for all external drives. With this, you can encrypt your external disks using (I hope) a decent passphrase, have the drives available for mounting automatically, and save the recovery volume key offsite somewhere secure.
This is less the admin's fault than management. Part of what is taught in business school is the "run over the bus" adage, and not having your business be dependant on one person. Other departments (finance, purchasing) usually have well established procedures should someone quit. A upper level corporate officer who believes that IT is any different has not done their job, just as a sysadmin who didn't plan for a server to fail and lose mail didn't do his/her job.
The small server market is not new. Microsoft has been honing Windows Home Server for people who have a number of PCs at home, and want a place for backups and a core file repository. For Mac users, a Mac Mini connected to a number of disks, or a hardware RAID device like a Drobo would offer similar functionality. A lot of Linux and BSD people have the samba server that used to be their game machine 3-4 years ago keeping the ISO images for their OS at the ready. Apple is smart to acknowledge this.
The only thing I wish Apple would have addressed in SL Server would be comprehensive hard disk encryption. A Mac Mini can vanish in a heartbeat, and the value of data stored on it would be far more than the hardware itself. Of course, TrueCrypt and mounting disk images help, but the ideal solution for a server would be something using a TPM and checking to see if stuff has not been tampered with before decrypting and mounting the critical filesystems. This way, a server could boot unattended, but someone trying to override OS XS's priv model by booting from OS media would have to know a recovery password in order to access the filesystem.
Excellent observations. I appreciate comments and corrections from someone who is versed in the field.
You are right about FPGAs. These days, instead of DSPs, buyers of this device would be better off with a FPGA solution and a software stack (OS/drivers/apps) that is able to reconfigure and use the hardware in the best way possible. This way, an audio app and a video app could have completely different configurations. The downside is that it would take engineering on all layers (hardware up to the UI) to have this ready to go for users.
Even though video is moving to SDHC cards as opposed to DV tapes, FireWire will still be something people want. A number of keyboards and dedicated musical instruments still use mLAN (even though it is becoming antiquated.) Of course, IEEE 1394 has better constant transfer rates which are vital for the large blocks of I/O needed for A/V work to and from disk drives. USB 3.0 is also a must have because this should be in day to day use when a device like this ships.
As for security, any general purpose computer these days should be built from the ground up with this in mind, perhaps throwing in a core or two hardware wise just to deal with the overhead of a hypervisor and the context switching it would require. Dedicated musical instruments that have a limited interface might not need to worry about compromise, but anything past that (especially any device that has a TCP/IP stack) needs to have security factored in from the design state on up. If solid security is not factored in, the arms race on that OS and hardware between blackhats and security patches may cause people to abandon the platform. The battlefield for the security battles needs to be determined early on, rather than try to be fought on the blackhats' turf. Ideally, the core music stuff would be in one VM, while general purpose computing (as almost everyone wants to run a variant of UNIX, and perhaps Windows) would be in another VM (of course, the owner of the device would have the option of replacing the installed OS with whatever he or she feels like unlike the PS3, but having the ability to run Windows in a VM is likely a small sales point.)
If I were to hazard a guess, it would be so that any possible show-stopper bugs would be found and hopefully fixed before the public got their hands on the copy and the rumor game started up.
MS was bitten by this with Vista. Once Joe Sixpack heard from his friend who is slightly more technical than he was, that Vista sucked (even though the reasons why were not listed), Vista rapidly got a bad reputation that it could not shake even with multiple service packs and several generations of hardware. With Windows 7, should there be any real nasty issues (and so far, there are not), Microsoft has some lead time to get them pushed to Windows Update before the product faces judgment by the masses.
There are a few niches where an OS that is dedicated for video and audio would be nice. When I mean dedicated, I mean with the facility for as low latency as possible, and full realtime capabilities.
Combine this with hardware that has multiple cores (not just the same type, but perhaps some cores that turn on for higher CPU tasks, while basic I/O loops are handled by low power cores, as well as cores for DSP use.)
Of course, ports are necessary. USB ports on different I/O channels (so the hard disk would be doing I/O on a separate bus from MIDI controllers.) IEEE 1394 (400 and 800), AES/EBU, S/PDIF, multiple channels of analog in/out, multiple MIDI channels, gigE, and eSATA channels would all be a must. IMHO, historically the two machines which had the "ports for your musical storm" were the Amiga, but there was another machine which had an amazing amount of things, and that was the SGI Indy.
The result would be an OS and hardware platform that would be genuinely idea for a studio or video production system. The low latency would mean that one can pile the tracks on (with quality ADCs and input hardware, 48-96 isn't out of the realm of possibility.)
Now, take all the above and focus on optimizing for A/V work for not too high a price, and the Commodore successor would have a place in every home studio and video lab out there.
The key would be having the machine not just have the DSPs and the cores to throw at A/V jobs, but have the software available that can handle stuff like VST plugins out of the box. This way, someone buys the machine, takes it home, plugs the I/O stuff in, and starts jamming.
Filesystem wise, it would be nice to see a later generation filesystem like ZFS present. This way, data integrity is assured (64 bit CRCs), adding storage space becomes easy, snapshot functionality allows recovery of corrupted/deleted files without requiring a restore from backup, and backups become easy because one can just make a snapshot, copy it off to disk or tape and call it done. It would take some UI design work to make a robust interface so a nontechnical person could get the most out of ZFS or btrfs, but it can be done.
Last, but not least security: Probably the best way to implement modern security is to have a hypervisor that does its tasks on a dedicated CPU core. The music stuff sits in one VM, the Web browser sits in another (or at least in a BSD-like jail), and so on. This way, if a blackhat managed to take over one VM, the whole system wouldn't be at risk. Of course, signed executables, ASLR, install-time profiles [1], TPM [2] and disk encryption would be present.
Conclusion: If someone took the time to bring AmigaOS up to speed and aim for the audio/video niche with hardware in the machine to handle the demands, I'm sure that this would be a machine that would sell well. It won't sell as well as Macs, HPs, or Dells, but it would always be needed and a profit center if done right.
[1]: Upon installation of an application, it comes with a list of access lists that it requires, another list of stuff that would be nice, and a maximum permission list (so a program that touches untrusted stuff like a Web browser isn't accidentally run with root rights). Once the program is installed, unless a patch is applied that asks the user for more permissions, it doesn't get any more access than what it originally asked (and got approved for). This limits the damage a hijacked app can do. For example, if a spreadsheet tries to access an unrelated database file, the OS will deny it access.
[2]: TPMs are controversial, but here it would be a net benefit to the user to detect if a blackhat has tried booting from OS media and resetting passwords in order to gain access, or some malware tried editing the boot area.
That actually might be a viable attack vector. I could imagine someone giving out ready to install media for popular distributions, except that a few key binaries would be modified (including gpg so it would say that things are signed when they really are not.)
The main defense to this is for Linux distribution makers to make media with anti-counterfeit features like holograms, or for a person to burn the media themselves after checking that the signatures match on a machine they know is not compromised.
Slashdot Mirror
DRM isn't the right term here. DRM is for locking away content. Instead, what is needed is trusted computing. This is a double edge sword, on one hand, it can be used for making closed appliances like consoles. On the other hand, it can ensure that the contents of a stolen laptop are not accessible even to an intruder who manages to briefly gain access to install a bogus MBR.
For a voting machine, the best way would be to have an open source OS [1], a TPM, and a boot path that would not allow decryption of the root filesystem or any other filesystem containing data if the kernel, MBR, BIOS, or boot sector has been modified. Of course someone can attack the TPM chip, but this requires access to a chip fab and James Bond style tech, not just someone with a USB flash drive and a screwdriver.
Maybe Infineon and the Trusted Computing Group could work on a specification designed with open source operating systems in mind so transparency is maintained as well as security.
[1]: OSS operating system of choice. This could be Linux, BSD, or any other operating system with the source code available for study and runnable in a VM.
Darknets are bandied about from time to time, but their traffic has to cross the Internet in some form or another, because rogue links are just not practical. All it would take is some smart QoS programming to drop any unknown encrypted traffic, and darknets will be relegated to the same status as pirate broadcast radio; doable in some small areas, but not on any real basis. One can play cat and mouse with ports, but darknet traffic would have an obvious signature -- lots of volume, and connectionless. This is easy for any SPF to spot and either log (giving the originator a strike), or dynamically throttle/block.
You might not want that. Laws or treaties can be enacted to force hardware DRM stacks built into every computer (think the PS3), and NAC like functionality on routers and gateways to ensure that machines that connect onto the Internet have such chips that would tag each packet with individual PC metadata (which is easily traced.)
Obligatory car analogy: Look how some states' lawmakers want to install GPS monitors on every vehicle in their borders. Already, any car made in the past decade has an EDR which has a log in a crash of what speed the user was going, brakes applied, and such. 90 years ago, there were no tracking systems for cars, and people didn't think of it. Computers are at the same place.
Maybe FB and Myspace need to move to a different business model, perhaps something up front.
Here is something I'd like to see. A social network that would cost up front something a month. I pay $3 a month to last.fm just so I don't have to bother with ads, so perhaps something around that. A small fee also will slow down spammers who create dummy accounts, because they either have to cough up cash, or start committing credit card fraud in order to continue.
Then, a chunk of the incoming revenue is given to the app writers. If a lot of people play a certain program, the app writer gets a fatter check from the social network. This way, a good programmer could write something and get paid for it without having to resort to trying to sneak $10/month shenanigans into their app.
Of course, advertising revenue can come in too, perhaps offer a two tiered system, free accounts with the usual crapola Flash ads, and paid accounts which don't inflict such stuff on their users.
I started using FB the same reason I created accounts on MySpace and Twitter. Prospective employers want that info, and think that you are behind the times or a Luddite if you don't have it. This was told to my face in a couple interviews I've had.
So, I created a dummy MySpace account that has nothing on it, and only bother logging on to check out bands. My Twitter account has no tweets from me, and it follows a lot of major brands in the industry (IBM, EMC, Microsoft, SOE, Cisco, etc.) FB, I actually use and have some friends there and use it as a messaging source, as well as a way to keep up on a couple events going on.
Maybe this is a pipe dream, but I'd like to see a social networking website where every object (post, movie, file) was considered an object, and each object had security ACLs, similar to how every filesystem object. So, if I want to allow everyone to view something, I'd add the everyone ACL which adds their public key to the object. I'd also have ACLs that are for denying access, so I can explicitly prevent people (or groups) from seeing an entry regardless if they are a friend or not.
This was because Hushmail was forced to either allow the Interpol (which has clout in Ireland and other places Hushmail has their servers) to read what the server decrypted via the Javascript client, or likely face shutdown for not cooperating.
There is absolutely nothing Hushmail's developers could have done once the judge in their area handed the search warrent papers. I still highly recommend using the service, not just for E-mail, but a decent place to store some documents offsite.
Even better, either use a utility like KeePass or roll dice and use Diceware's password generation to make a 64 bit passphrase. Essentially, you really don't need to remember it like you do your router password. Then save the passphrase to a USB flash drive. After pasting it into your router, take the USB flash drive from wireless box to wireless box, copy and paste it in their configs, then either encrypt the usb flash drive key file, or merely store it in a secure place.
This way, an attacker isn't dealing with a 10 character passphrase (might be tough), nor a 20 character passphrase (virtually uncrackable), but more than the 256 bits used in AES. With using a passphrase that has upper/lower case, numbers, and symbols, and all 63 characters (the maximum length passphrase in WPA2-AES), now the door is stronger than the wall.
This is more of a matter of peace of mind, but it also doesn't hurt to change the AES key every so often. I like changing the WPA2 keys out every three to six months, or when I remove a machine from the network to be safe.
Of course, the best security is having a RADIUS server that uses smart cards, and a WAP that can authenticate people from that. This way, for someone to get access, they would have to get physical possession of a cryptographic token, and either know the passphrase, or guess it before the token permanently blocks access.
After you have your WPA2 key done right, you don't need to bother with hiding your SSID (doesn't protect against anything), and you can use an authorized MAC list if you want, but it really doesn't provide that much security.
I had a machine with an nVidia chipset with this semi hardware firewall functionality. At first, it worked quite well, and it supposed some pretty detailed access lists (no outgoing port 25), but after a couple patches, it didn't seem to work right, so after a reinstall due to unrelated issues, I didn't bother installing the nForce drivers.
Overall, I like the idea of having the onboard NIC have router functionality in hardware so packets can be denied and/or filtered before they ever touch the OS. However, I'm sure this functionality will bring substantional added cost, not for both the chips to run a router (CPU, RAM and some storage), but standardized drivers so any OS can easily add/subtract access lists. Of course, the firmware for the NIC interface would have to have its own signing and validation capabilities so malware that roots the main machine can't just quietly flash the NIC and leave an firmware based botnet client. This would be a nice option in premium motherboards though, where one doesn't have to worry about cutting every penny.
You hit upon something here. There are a lot of IT related fields. One can be a sysadmin, a DBA, an admin watching over developer projects, an architect who designs infrastructure, the network admin who sets up the core/edge structure, the implementers who implement, the security auditor, the corporate compliance people, etc.
I wonder if people might be better off changing their IT field, rather than leaving the industry completely and starting from ground zero. For example, changing from a sysadmin specialty to a DBA would require a lot less retooling than changing completely out of IT and not having any common skills.
That is the issue right there: There is no good archival medium for typical users. Perhaps if you get the CD-Rs touted to have a 100 year lifespan and store those vertically in a climate controlled environment, you might have the best luck, but in reality, your best bet is storing the data in multiple archive formats and on multiple types of media. For example, a tar achive, a zip archive, and a winRAR archive with recovery records, then storing those files on a hard disk, burned to multiple CDs, stored on cloud storage, etc.
The only medium I know which would have a truly long shelf life would be printing stuff out on acid free paper in black and white. However, something that can come close would be how one of the old IBM mainframes used to store WORM data. It had a roll of unexposed black and white film (same as what is used in cameras). Then, once the roll was "written" to by exposing it, it would be automatically developed, washed, then fixed, and moved to a library for permanent retrival of the bits. This likely could last a long while, assuming a safe environment, and no chemical issues with the plastic that would cause degradation.
Most operating systems also support hybrid hard disks. I haven't seen many ReadyDrive drives, but I'm sure if there is a market impetus for them, drive makers will happily tack on some flash memory and sell them.
I see hard disk capacity increases slowing down, but in order to remain competitive, HDD makers will start adding more useful features, such as hardware based disk encryption, additional steps for data integrity (multiple heads, multiple "drive-lets" for one drive that has two mirrors with separate platters/heads, more RAM for cache, etc.)
There is one big advantage that HDD makers have: They can add flash storage to their offerings with relative ease, while the other way around is difficult to do for chipmakers. I can see not just hybrid drives, but drives that appear to an OS as multiple volumes. For example, a drive that has 16 to 64 gigs of flash storage for static binaries (OS files), and 2-4 TB of spinning storage for the rest of the data.
HDD makers also have a lot more room to play with than a SSD company, so they can add special features on a drive just for certain tasks, be it enterprise RAID (and ensuring the drives stay in sync), A/V uses (to ensure streaming), encryption co-processers to have enterprise level encryption key management, and so on.
The TPM really doesn't actively encrypt. It never is an active part of the boot process. All it does it get reset on boot, get cryptographic hashes passed to it periodically, then either unseal the key or give the middle finger for the request.. In theory, it could be used to check if a machine was tampered with by asking for the sealed key, and if the TPM wouldn't give it up on boot, then print out that something, somewhere, along the boot path got modified.
However, without encryption of vital data to prevent the booting from completing no matter how bongoed the boot loader and kernel end up, an attacker could just have the bootloader say that the machine always passes the test.
If you want as minimal encryption as possible, you likely are best served by having / encrypted, so the boot process would continue to the point of passing code, then the moment of truth would be if the machine gets to a multi user mode, versus hanging during the init process and asking for the filesystem's recovery key.
When configuring BitLocker to encrypt, unless you do it from the manage-bde utility (a .wsf script in Vista/Windows Server 2008, and an executable in Windows 7/Windows Server 2008 R2), BitLocker will demand that you save a copy of the volume recovery key to non encrypted media. I personally save it to a mounted TrueCrypt volume on a removable drive, and in a password manager on a non connected PDA. This way, should the TPM not work the way it should, all it takes is opening my PDA, typing in the code, getting into Windows, and disabling the TPM key protector until I find out why the TPM went on vacation.
Also, this is a Windows solution. It would be nice to see RedHat and other distro makers use LUKS and a TPM to have similar functionality, but as of now, there are some projects in alpha that one can look at.
This is definitely an itch that someone should scratch on Linux/BSD/OS X, and other places. It would help security of Linux distros immensely. The TPM 1.2 spec is a standard that requires no drivers either.
The TPM is essentially a smart card. It stores the decryption key until asked for it, and the values match. (Technically this is a bit more complicated because on bootup the TPM state is reset, and each part of the boot process scans the next part, passes the cryptographic hash to the TPM, and the TPM then hashes the hold and new parts for a value, and this process of adding and rehashing repeats until the TPM is asked for the key.)
If someone yanks the TPM (some PC motherboards have the chip on a daughter card), then there is no usable key to use for decryption (barring access to recovery media, rubber hoses, or another way to find the key).
Most of the HP business class subnotebooks (HP EliteBook 2730p is one, there are others) have TPM functionality built in. Not all have the functionality built in, and in general, you will be paying a business class price for the security.
It is worth it though. Mainly because you can just set BitLocker (making sure the recovery key is stored somewhere safe) and essentially forget you have hard disk encryption present.
Not just BitLocker works with TPM chips for security software. I know that PGP's WDE product works as well, and for some people that don't want to run Vista or Windows 7, they can get similar protection from tampering by using PGP and the onboard TPM.
If physical security on TPM chips even becomes more than a slight issue, most likely what will happen is that the TPM functionality will move from today's existing chip that doesn't have physical protection, to chips which are epoxy potted onto motherboards (like any video chips that deal with Blu-Ray. The spec requires the maker to drop a blob on epoxy on them to prevent reverse engineering). For high security, I'm sure that the TPM and critical parts of the machine's BIOS will be moved into a metal security container with epoxy potting, as well as multiple tamper mechanisms that will zero out the contents should the case be breached, similar to how smart cards and PCI based key storage modules work today.
FDE has been around since the days of Macs and FWB Hard Disk Toolkit doing a modified (2 rounds IIRC) version of DES on any external hard disks (or Casady and Greene's A. M. E. doing a full DES on disks). It does have a performance it, but from what I've seen (and I've been using WDE in many platforms for a long time), the hit is not an issue with almost all FDE types of programs.
Encryption is a tradeoff. Yes, you lose reliability. However, if you have a decent backup mechanism (and you should regardless of the presence of encryption), the reliability loss isn't much, assuming you remember your password or keep your keyfiles safe.
The last assertion of being easier to break into encrypted data doesn't make sense. I can see people installing a FDE utility then assuming they are safe from all attacks (including ones via remote). If a person is concerned about data, perhaps it might be wise to install TrueCrypt in addition to the FDE security to only mount sensitive files when used and dismount them immediately. This way, should the laptop be seized while on and the memory dumped, an attacker would not have access to the whole filesystem. Similar functionality can be accomplished with multiple users on Windows and EFS.
Oh, the chosen plaintext attack would be a problem if people kept using 64 bit blocks and lame implementations of encryption like ECB. However, with modern algorithms that use a bigger blocksize and a more advanced diffusion protocol which uses a different subkey per sector, an attacker can know all they want to about plaintext, but it will not help them discern the key. The TrueCrypt manual has a good section on this.
Windows 7 is different from Vista in the way businesses and enterprises use it. Vista had two editions that were activated via an internal KMS system (very important when you have thousands of PCs and do not want them touching the Internet for activation). Windows 7 has only one edition that has this functionality, the Enterprise edition. This is available via volume license key agreements. Other than the MAK/KMS model of activation, this edition is the exact same as Ultimate which has BitLocker, BranchCache, and the other items.
So, if a company is using a volume license of Windows 7, they will have access to BitLocker functionality. Server-wise, Windows Server 2008 and Windows Server 2008 R2 both have BitLocker functionality built in.
This way, if a corporation that is running Windows 7 orders a bunch of laptops, they would be fools not to order ones with TPM chips because their OS will easily support this functionality. If they have an Active Directory infrastructure and no existing encryption product (PGP, PointSec), getting BitLocker deployed enterprise wide wouldn't be too difficult with AD holding recovery keys to machines.
I'm glad Microsoft did this. No worry if a company has Business or Enterprise editions for features (like the issues with Vista). Now, if a company has a VLK and uses a key management server for internal activations [1], they have BitLocker available with W7.
[1]: I'm not a fan of activation at all. Personally, my wish is they would have gone back to how XP VLK editions handled this. Businesses are not going to be pirating Windows because the BSA will come for a visit. Pirates will crack any activation. So, there is no real antipiracy benefit to Microsoft in forcing businesses to have an activation infrastructure.
Be careful on saying an attack may not be used widely. Virtually these exact words were said in the late 1990s about ssh and only paranoids having to worry about packet sniffers and session hijackers.
Now, ISPs have appliances whose job it is to insert ads in unencrypted HTTP transfers and transparent Web proxies are fairly easy to set up by anyone knowledgeable. Any business class router supports packet logging, so anywhere between your machine and the host you are connecting to can record every single packet from the SYN to the final ACK.
As of now, the "evil maid" attack may seem farfetched, but in reality, there are many ways to separate an exec from his or her laptop without them getting alarmed. One of those can be done at any border checkpoint where the laptop is taken to be "further inspected" while the exec is being strip searched. All it would take would be a simple bootup from a USB flash drive that scans for popular encryption program headers (TrueCrypt, PGP, PointSec) and some code inserted to save the preboot authentication passphrase somewhere safe for later. This wouldn't take much technological knowledge on the end user side, because all they do is jam the flash drive into a port, tell the laptop to boot from the drive, and then turn the laptop back off. Should the laptop have locked or no USB ports, the drive itself can be removed from the laptop and put into a machine that would do similar functionality (detect encryption, modify the bootloader).
After this is done and the person stays in the country a bit, the laptop can be quietly imaged by outgoing customs or airport security, or just outright seized by security.
The best BitLocker protection is a combination of PIN + TPM + USB flash drive. This way, if a thief rips off your laptop, but you have your USB flash drive with you (either in your wallet, around the neck, or on a keychain), you are pretty much assured that they will not have access to data, no matter what they try.
For additional protection since Windows 7 has been released to everyone, perhaps consider BitLocker To Go for all external drives. With this, you can encrypt your external disks using (I hope) a decent passphrase, have the drives available for mounting automatically, and save the recovery volume key offsite somewhere secure.
This is less the admin's fault than management. Part of what is taught in business school is the "run over the bus" adage, and not having your business be dependant on one person. Other departments (finance, purchasing) usually have well established procedures should someone quit. A upper level corporate officer who believes that IT is any different has not done their job, just as a sysadmin who didn't plan for a server to fail and lose mail didn't do his/her job.
The small server market is not new. Microsoft has been honing Windows Home Server for people who have a number of PCs at home, and want a place for backups and a core file repository. For Mac users, a Mac Mini connected to a number of disks, or a hardware RAID device like a Drobo would offer similar functionality. A lot of Linux and BSD people have the samba server that used to be their game machine 3-4 years ago keeping the ISO images for their OS at the ready. Apple is smart to acknowledge this.
The only thing I wish Apple would have addressed in SL Server would be comprehensive hard disk encryption. A Mac Mini can vanish in a heartbeat, and the value of data stored on it would be far more than the hardware itself. Of course, TrueCrypt and mounting disk images help, but the ideal solution for a server would be something using a TPM and checking to see if stuff has not been tampered with before decrypting and mounting the critical filesystems. This way, a server could boot unattended, but someone trying to override OS XS's priv model by booting from OS media would have to know a recovery password in order to access the filesystem.
Excellent observations. I appreciate comments and corrections from someone who is versed in the field.
You are right about FPGAs. These days, instead of DSPs, buyers of this device would be better off with a FPGA solution and a software stack (OS/drivers/apps) that is able to reconfigure and use the hardware in the best way possible. This way, an audio app and a video app could have completely different configurations. The downside is that it would take engineering on all layers (hardware up to the UI) to have this ready to go for users.
Even though video is moving to SDHC cards as opposed to DV tapes, FireWire will still be something people want. A number of keyboards and dedicated musical instruments still use mLAN (even though it is becoming antiquated.) Of course, IEEE 1394 has better constant transfer rates which are vital for the large blocks of I/O needed for A/V work to and from disk drives. USB 3.0 is also a must have because this should be in day to day use when a device like this ships.
As for security, any general purpose computer these days should be built from the ground up with this in mind, perhaps throwing in a core or two hardware wise just to deal with the overhead of a hypervisor and the context switching it would require. Dedicated musical instruments that have a limited interface might not need to worry about compromise, but anything past that (especially any device that has a TCP/IP stack) needs to have security factored in from the design state on up. If solid security is not factored in, the arms race on that OS and hardware between blackhats and security patches may cause people to abandon the platform. The battlefield for the security battles needs to be determined early on, rather than try to be fought on the blackhats' turf. Ideally, the core music stuff would be in one VM, while general purpose computing (as almost everyone wants to run a variant of UNIX, and perhaps Windows) would be in another VM (of course, the owner of the device would have the option of replacing the installed OS with whatever he or she feels like unlike the PS3, but having the ability to run Windows in a VM is likely a small sales point.)
If I were to hazard a guess, it would be so that any possible show-stopper bugs would be found and hopefully fixed before the public got their hands on the copy and the rumor game started up.
MS was bitten by this with Vista. Once Joe Sixpack heard from his friend who is slightly more technical than he was, that Vista sucked (even though the reasons why were not listed), Vista rapidly got a bad reputation that it could not shake even with multiple service packs and several generations of hardware. With Windows 7, should there be any real nasty issues (and so far, there are not), Microsoft has some lead time to get them pushed to Windows Update before the product faces judgment by the masses.
There are a few niches where an OS that is dedicated for video and audio would be nice. When I mean dedicated, I mean with the facility for as low latency as possible, and full realtime capabilities.
Combine this with hardware that has multiple cores (not just the same type, but perhaps some cores that turn on for higher CPU tasks, while basic I/O loops are handled by low power cores, as well as cores for DSP use.)
Of course, ports are necessary. USB ports on different I/O channels (so the hard disk would be doing I/O on a separate bus from MIDI controllers.) IEEE 1394 (400 and 800), AES/EBU, S/PDIF, multiple channels of analog in/out, multiple MIDI channels, gigE, and eSATA channels would all be a must. IMHO, historically the two machines which had the "ports for your musical storm" were the Amiga, but there was another machine which had an amazing amount of things, and that was the SGI Indy.
The result would be an OS and hardware platform that would be genuinely idea for a studio or video production system. The low latency would mean that one can pile the tracks on (with quality ADCs and input hardware, 48-96 isn't out of the realm of possibility.)
Now, take all the above and focus on optimizing for A/V work for not too high a price, and the Commodore successor would have a place in every home studio and video lab out there.
The key would be having the machine not just have the DSPs and the cores to throw at A/V jobs, but have the software available that can handle stuff like VST plugins out of the box. This way, someone buys the machine, takes it home, plugs the I/O stuff in, and starts jamming.
Filesystem wise, it would be nice to see a later generation filesystem like ZFS present. This way, data integrity is assured (64 bit CRCs), adding storage space becomes easy, snapshot functionality allows recovery of corrupted/deleted files without requiring a restore from backup, and backups become easy because one can just make a snapshot, copy it off to disk or tape and call it done. It would take some UI design work to make a robust interface so a nontechnical person could get the most out of ZFS or btrfs, but it can be done.
Last, but not least security: Probably the best way to implement modern security is to have a hypervisor that does its tasks on a dedicated CPU core. The music stuff sits in one VM, the Web browser sits in another (or at least in a BSD-like jail), and so on. This way, if a blackhat managed to take over one VM, the whole system wouldn't be at risk. Of course, signed executables, ASLR, install-time profiles [1], TPM [2] and disk encryption would be present.
Conclusion: If someone took the time to bring AmigaOS up to speed and aim for the audio/video niche with hardware in the machine to handle the demands, I'm sure that this would be a machine that would sell well. It won't sell as well as Macs, HPs, or Dells, but it would always be needed and a profit center if done right.
[1]: Upon installation of an application, it comes with a list of access lists that it requires, another list of stuff that would be nice, and a maximum permission list (so a program that touches untrusted stuff like a Web browser isn't accidentally run with root rights). Once the program is installed, unless a patch is applied that asks the user for more permissions, it doesn't get any more access than what it originally asked (and got approved for). This limits the damage a hijacked app can do. For example, if a spreadsheet tries to access an unrelated database file, the OS will deny it access.
[2]: TPMs are controversial, but here it would be a net benefit to the user to detect if a blackhat has tried booting from OS media and resetting passwords in order to gain access, or some malware tried editing the boot area.
That actually might be a viable attack vector. I could imagine someone giving out ready to install media for popular distributions, except that a few key binaries would be modified (including gpg so it would say that things are signed when they really are not.)
The main defense to this is for Linux distribution makers to make media with anti-counterfeit features like holograms, or for a person to burn the media themselves after checking that the signatures match on a machine they know is not compromised.