If it has to have a flash BIOS for some reason, why does the flashing utility allow any image to go in without notice? Something like this should either require a signed or encrypted image that the flash utility decodes and decides is correct before putting it in. Maybe something simple as holding a distinct key sequence down on the keyboard while the utility pops up might be an alternative. This way at least the user has to be duped into knowingly flashing the keyboard, as opposed to a completely stealth compromise.
If I were making a keyboard with a flashable BIOS, rather than going the easy route and hiding a symmetric key on the chip would be eventually discovered, I'd use a SHA256 hash combined with an elliptic signing key to validate that a BIOS image was not tampered with before allowing it to be copied to the device. Yes, (barring someone breaking the public key crypto or obtaining the private key) someone could hack a particular keyboard to accept any flash image, but it would require physical access to the JTAG contacts on the device, and its well known that the game is over when an attacker obtains physical access to a machine anyway.
Not sure if its time for AES2, but...
on
Another New AES Attack
·
· Score: 3, Interesting
Even though AES is far from being truly broken, I wonder if it's time for NIST to start working on the AES2 spec. Maybe Serpent would be a good candidate because it was discussed that it had a larger margin of safety than Rijndael/AES.
As stated in TFA, attacks only get better and better, so every decade or so, maybe it would be time to consider another standard encryption algorithm. The reason DES lasted so long as an algorithm was that cryptography was not as vital to day to day operations as it is now, so a complete break would have been more of an academic excercise than one that would get the cryptographer financial gain. These days, if a blackhat does a break, or reduces the keyspace to a low level where brute forcing is possible, there are billions of dollars to be gained.
This is the solution that most BIOSes use for ATA hard disk locking. Due to the possibility for rogue programs putting on passwords onto hard disks, a feature was introduced to lock out any modifications to this functionality in drives other than on the BIOS level. This helps prevent OS level malware that would render drives unusable.
Flashing should be the same. Go into BIOS, insert a USB flash drive, load up the file, have the flashing utility do some sanity checks to ensure that the flash image is actually usable on that machine and motherboard, then finish the flashing. Of course, there should be a backup BIOS should power fail or something bad happen with the image that was flashed.
Maybe a centralized internal mirror server, perhaps two servers would be ideal for this type of work. One machine sits on a DMZ and does full time bit swapping, with the P2P client throttling bandwidth at peak hours. This machine then writes the shared files to a samba server which is used for the internal mirror. By bifurcating the duties, if the P2P server gets compromised, damage can be limited, especially if seeds are kept on a read only share.
Then employees can send in a ticket for a request to mirror some ISOs, say if the latest Slackware CD comes out.
With BitTorrent mainstream, there isn't much reason to bother with Kazaa, LimeWire, and other apps. BitTorrent isn't perfect, because finding a seeder is tough sometimes, but it is almost impossible to accidently share confidental data (accidently being the keyword here) unless someone manages to create a torrent, pass it to a tracker, start seeding, then pass the torrent file to a search engine while asleep.
Its not P2P in itself that is wrong. It is the use. The leaked information could have wound up on a website, blog, or FTP server, and I'm almost sure nobody would be saying that those technologies should be banned.
Even though piracy [1] is more akin to freeloading than theft, there are several cases where a company loses resources to pirates. One of them is bandwidth. Pirated copies grabbing updates and additional content cost the game publisher bandwidth (and bandwidth is almost always metered.) There are also pirates who tie up support lines. Both of these consume resources.
IMHO, I think the best thing to do is have a CD key system that comes into play for multiplayer (not LAN) play, and for downloading patches or additional DLC. When the game is at EOL after 3-4 years, patch the servers to allow any client to connect, not just the clients with valid CD keys, and patch the clients either with a universal key, or patch out the CD key algorithm completely. This way, should someone want to play the game in the future where it is sort of abandonware, it can be done with relative ease. Another idea is after the game EOLs, is to offer a final archive with every single thing in it, so the patch servers can be shut down, but anyone who wants the last build can go grab a self extracting file with that content in it.
Server-side this implementation of checking for updates is fairly simple. The client selects a server at random from its list (for load balancing reasons), sends a SOAP packet to the server over a SSL protected connection with the version of the game, the edition (standard, deluxe), a hash of the CD key [2], and the platform the game is on. The server hashes the CD key hash, checks that against what it has stored. If the second hash of the key is in a database, the server then redirects the client to a temporarily generated URL to obtain whatever additional content is offered.
[1]: Meaning "casual", non profit IP infringement. However, there are people who counterfeit games, with the box, packaging, logos, and media. Then they try to sell those to unwary customers. This type of piracy is actual theft because the offender gains cash and the game company loses a sale.
[2]: Valid CD keys should be tucked away in a database, and hashes used. This way should someone compromise the validation server, they won't be able to obtain live keys.
Part of the reason for this is that PHBs are more easily swayed by a smooth talking salesman selling a shiny new appliance that looks good in a rack, as opposed to a desperate IT manager who needs more headcount for admins.
Another reason is that employers in general are averse to hiring people right now. If some security appliance costs $200,000, it is a lot more attractive to the people with the purse strings than a $50,000/year admin. Mainly because of the philosophy of "machines don't get disgruntled" that some business schools teach.
In a recession, security is the last thing a business should cut.
The unemployment rate is high. This means that people who wouldn't think of things in normal times would turn to other means to supplement their income to keep a roof over their family's heads. So, someone who would normally give the finger to someone overseas asking for brief use of a username/password for $500 would happily give it in these times in order to keep the repo man away for another month.
More criminal organizations (domestic and overseas) realize there are profits to be made in capturing data stolen laptops for not just hardware, but the data on the machine. The data can be sold, or used to blackmail or extortion.
Employees are more likely to be disgruntled due to layoffs and cutbacks. So, vandalism and outright internal theft is on the rise.
There are a lot more regulations than before that make companies face shareholder lawsuits and corporate officers face prison time should a major breach occurs and a breach in process found.
Software CD keys are worth money, and a divulged volume CD key can force a company to re-buy every single license of a product as per EULA stipulations.
Outside attacks are more and more sophisticated as time goes on. To use an auto analogy, car companies are not using the same disc cylinder used on autos in the 1950s; they have moved to sidewinder cuts and "laser cut" keys. Same with security. A company has to keep abreast of new threats as a matter of life, just as CCTV cameras and bump-resistant locks on the doors are now the standard.
Thanks to Enron and other companies, and the knee-jerk regulations put into place after that like Sarbanes Oxley, a security person has to be familar with all these laws, like ISO 9000, ISO 10000, PCI-DSS.
Yes, you will be doing tons of TPM reports to ensure that the company is compliant, but if a company doesn't have the CYA papers, and something happens, there is a chance of prople facing prison time, and shareholders suing.
Its just how the game has changed. Locksmiths used to forge custom locks out of metal, now they use existing technology to suit a customer's needs with master key lists.
The trick is finding a security professional who knows this, and is able find the security tools that turn the company's policy, their security needs, and budget into implementable technology. A company can buy every single product sold in SC Magazine and the CISSP magazines. It won't do them much good because even the best security product will not give much protection if not implemented right.
For example, take a high grade HSM (hardware security module). If the admins of it allow everyone and their brother access to the signing key stored on it, or had the key flagged to be exported in an insecure manner, the security that the device provides is minimal.
Communication is key here. The reason why a security professional is a professional is that they have to have the knowledge to take what the client needs, their budget, the regulations the client is operating under, and the contracts of the client's customers and vendors. He or she needs to take that information and do two things: Buy the equipment, and configure it correctly. It's not just knowing all the technical stuff, but knowing how the company functions to put in a complete system that impacts productivity as minimal as possible, but yet provide protection against both known threats and unknown threats (zero days, unexpected threat vectors like compromised printers, etc.)
If there is a limited budget, a security pro has to get with the corporate officers and figure out where most likely attacks will come from. For example, a nontechnical call center has a high threat of physical theft of equipment, so they would be going with physical security, CCTV, enterprise systems to detect case intrusion events, and perhaps some form of encryption on all machines so if a machine or hard disk is stolen, licensed software and CD keys are protected. A credit card processor would be more concerned about network and perhaps social engineering attacks (although physical is still a concern).
I'm also curious not how much MSRP + TT&L, but how much in service costs? Part availability and price can be a major overall cost factor over a vehicle's lifetime.
Some questions I have, if this hits production:
Do mechanic shops have to have specialized equipment to work on this vehicle? Do I have to wait days to weeks for a battery pack to come in? Hybrid batteries have a longer lifetime than the 1 year expected life of a laptop battery, but the lifetime is definitely finite until supercap technology is able to be mass produced. How difficult and expensive will it be to get parts like bumpers, quarter panels, and other stuff that sometimes needs replaced due to drivers drunk or on cellphones? How often does the vehicle need serviced? Newer cars only need taken in for oil changes pretty much. However, there are some older foreign cars which require a complete engine rebuild every 25,000 miles.
I always love seeing new car ideas, but for my main vehicle, I go for the tried, true, and commonly available, even though it may be boring.
The TPM boot process works off of "scan the next segment to be loaded and executed, pass the hash to the TPM". The TPM then keeps track of the hash process and when asked to unseal a key, either hands the key over if the cumulative hash matches, or refuses.
The TPM never is an active part of the boot process, it just sits there, accepts hashes, then either hands a key over, or doesn't.
Advantages of this in a FDE system:
Replacing the preboot authorization (PBA) code cannot be done without detection. The TPM can be configured to ask for a password before unsealing the key. Too many wrong guesses, it will delay longer and longer. The TPM is shipped disabled, and has to be explicitly enabled in BIOS. Using a TPM for key storage means a machine boot unattended and can handle multiple users, but booting from other media is prevented. Say two people are sharing a laptop, neither could get at the other's files unless they have root/Administrator access.
Disadvantages:
The chip isn't hardened. A well heeled attacker who has access to a chip fab could probably disassemble the chip and pull out the sealed keys. An unintended upgrade or change (enabling or disabling Hyper-V) without resealing the new code may result in the TPM not unsealing the key. Not many machines have TPM chips. Concerns about "trusted computing" being used for hardware-based DRM.
Maybe Microsoft could have this as part of the Windows Logo requirement. This could be implemented in two ways:
The first is actively hosting all updates. The problem with this is that it would require very large amounts of bandwidth, so there would have to be a revenue stream to Microsoft for them to be able to do this and remain profitable.
The second is having a pointer to the vendor's download URLs for a file. This is a lot easier, but still requires some added infrastructure and bandwidth. However, third party utilities like Secunia's PSI are able to hunt down and point out outdated/insecure versions, so it wouldn't be too onerous for a central switchboard for application vendors to have one place for update checking. Acresso (formerly Macrovision) has this functionality in their FLEXnet Connect product.
This is probably answered by a conventional PKI. Alice creates a key and sends it into the cloud. Alice then sends a note to Bob signed with her private key, and encrypted by his public key the information needed to pick up the key from the cloud (which bits to grab from which servers.) Bob then decrypts the note supposedly from Alice, validates her signature and then fishes the key material from the cloud.
To me, the cloud is a inserted between the two normal steps in the cypher process (the first being the public key crypto, the second being a symmetric encryption key for the message's contents. All public key encryption systems use a symmetric encryption system and only encrypt that key because of performance reasons. Symmetric encryption algorithms like AES can be thousands of times faster than the algorithms used for RSA or DSS.)
Vanish reminds me of the anonymous remailers of the mid 1990s where people made long chains to get a message from their machine to a destination. Any remailer in the chain that did not log messages, or destroyed the logs would make it impossible without a side channel attack [1] to obtain proof that it really was Alice sent an anonymous E-mail to Bob.
If there are not that many Vanish peer nodes, they can be compromised and instead of discarding key material on the expiration date, merely retain or actively archive it. Then an attacker would then grab the material from the nodes, piece together the expired key and be able to obtain the message without harassing Alice or Bob. However, if there are a lot of Vanish peer nodes, especially ones on laptops or or the transitory machines, there is a chance that not enough machines would be online for Bob to get a quorum of pieces to reconstruct the key.
Another attack, if an attacker had the ability to gain access to a lot of Vanish peer nodes, would be to find all the key pieces that expired on an exact date or time, then attempt to use those pieces to reconstruct a key. To foil this, the Vanish client would have to set the expiration to a minimum time, then add a random factor (could be small, could be large, perhaps 2-3 times the original delay) on each piece to prevent someone from doing this.
Vanish is a trade off. Alice gains assurance that an attacker has a timeout limit to factor Bob's key and get the key material from the Vanish cloud before it gets destroyed. However, what is deeply impacted is reliability. If the message is critical, there is a chance it may not be re-constructable due to lack of pieces available (similar to what happens if there is nobody able to seed a torrent, and the people on that torrent don't have enough pieces to completely reconstruct the file.)
[1]: In theory. In reality, if someone of great interest is suspected of sending anonymous E-mail by a well heeled organization, they can monitor the encrypted traffic they send out and that the person sent a mail to one anonymous remailer, then there was an encrypted E-mail packet traffic went to the second one in the chain via SMTP, until the end where the last node sends it in plaintext to the destination. Yes, it would take someone sophisticated enough to be wiretapping every single network link, but it can be done. Of course, remailers that at random time intervals send encrypted E-mail to other remailers with a random sized encrypted packet that is chucked would stop this attack, similar with remailers that hold mail for a random time before being passed to the next node.
One advantage I see is that after the Alice sends Bob the message and Bob has it stored, then the copies of the message floating around on the Internet become completely non-decryptable after the time limit has expired. Even if a third party manages to decode or obtain Bob's private key, it won't do them any good in obtaining the text; the attacker would have to attack either Alice or Bob's endpoint, which is a lot harder than just passively sifting stuff sitting on a server with unknown security.
Vanish does the same thing that cryptographic tokens do. Both limit the window of attack on something. Where a smart card would limit guesses of a key's PIN to 3-5, Vanish limits the time of attack of a message to 8-12 hours.
Call your insurance company and see if you can get a rider for the netbook. Most rental plans and homeowner plans cover some computer equipment loss, but having explicit coverage of a computer against fire, theft, accidental microwaving, and other woes goes a long way to mitigate the loss of the hardware.
Theft still sucks since you are out your equipment, but at least you should be able to buy a new one when home with a good insurance plan. Always remember to get a police report if it does get stolen, because without it, you almost are certain to be not able to file a claim.
There are very lengthy discussions on the performance of full disk encryption. From what is usually stated, the performance overhead of a FDE program is very little, and not noticable by the average person.
It might come into play for a server doing large amounts of I/O to database container volumes, but for an OS partition, it shouldn't be noticable by most people, even on a lower power chipset like the Atom.
TrueCrypt is very good at this. The price is right too.
Two caveats:
If you can, carry a copy of the recovery CD with you. If for some reason, some program overwrites part of the boot track, you still have access to your data. Since TC stores the volume key on the boot track, if some utility or DRM system decides to write there (it shouldn't but a lot of them do to "individualize" the PC), it may make the TC volume completely unrecoverable without the recovery media. Each volume uses a different key, so you can't use a recovery CD from your desktop; you need to use the recovery media for that machine. This isn't just an issue with TC, other FDE (full disk encryption) programs might have parts overwritten, so its advisable to keep a recovery CD just in case.
Second, use a long passphrase. The days of using "passw0rd" or "letme1n" are long gone.
As for the dreaded inspection at airports, my advice would be to have two users (regardless of OS). The first user is one you are logged into when you pass the laptop to be inspected, and this user is a limited user (no access to sudo, not in the Administrators group). The second user is where you do all your work and have your home directory with your files. In most cases, someone inspecting stuff through an airport is more concerned that the laptop is a laptop and not anything nefarious.
If you want a "self destruct" feature, consider PGP or another FDE utility that supports cryptographic tokens like the Aladdin eToken. PGP has the ability to use a cryptographic token before booting, and if someone makes too many attempts at the smart card's password/PIN, it will either have a longer and longer delay between allowing attempts or lock out for good and permanently block access. TrueCrypt offers smart card support, but not for boot encryption, only mounted volumes. Of course, until you are completely convinced the cryptographic token is working, keep a backup passphrase so you can have access just in case.
For anti-theft protection, some laptops (don't know about netbooks) offer the ability to install Absolute Software's Lojack for Laptops into the BIOS. This way, should someone steal the netbook, completely zero out the drive and install a new copy of Windows, Lojack would silently install itself and phone home, allowing the stolen laptop to be traced by IP.
I use a similar system when offered by vendors. Blizzard has a keyfob, same with PayPal and eBay. Both of which are not technically SecurID, but OEM-ed VASCO tokens. My OpenID account on one site uses this keyfob as well.
What I wish for is someone to make a standard among the keyfobs, so regardless if someone has a SecurID card, a DigiPass Go, or a program that runs on a smartphone, they would be interchangable. Mainly so I don't need multiple keyfobs to authenticate to multiple sites, and it would be nice to buy a keyfob with selectable security features, be it merely pressing a button to see the 6 or 8 digit number, or more advanced measures like typing in a PIN, or swiping a fingerprint for three factor authentication (something you know, something you have, something you are.) Then take this standard for authentication and build it into all the popular OS logins, so the root password on a Linux box can be tied to one or more of these devices (so multiple people's keyfobs can authenticate).
Of course, it won't completely stop crime, but it will force malware writers to not just use passive keyloggers. Instead, they would be forced to go into more active man in the middle attacks against browsers (where the user is shown one thing while another action is being performed. IBM's ZTIC is the ideal solution for this.) This should be a lot more detectable though, as opposed to a keylogger that is just a driver hook away from silent operation.
All my machines went to IE8, even though I use Firefox as my browser of choice. Three reasons:
1: Security. You always want stuff that handles protentially hostile code as updated as possible. IE6 was made for the security threats of 2001. IE8 is made for far more current threats. Nothing is perfect, but IE has gotten a lot better as times have gone on. It has decent clickjacking protection, and seems to have had done a good job in standing up to NSS Labs's security tests.
2: Features. Auto-zapping all history and cache, and InPrivate browsing make it decently usable for those sites which require IE, or don't work well with Firefox.
3: Compatibility mode. There are some sites which still assume that everyone is going to be using IE6 for the forseeable future.
Most backup programs keep some type of checksum to check if files in a media set got damaged. However, if you want error correction, you likely will have to use an archiver like WinRAR, StuffIt Deluxe, QuickPAR, DVDisaster, or another utility that has this functionality built in. I have yet to encounter a backup app that has an option for Reed-Solomon ECC codes.
If I drop a tape on the shelf to the floor, I pick it up, check for physical damage, perhaps run a verify to be safe, and it becomes a non-issue. A DLT or LTO type of tape (media that isn't based around a consumer format) tape has to suffer heavy physical damage before data loss happens.
This is one of the biggest hard disk weaknesses. I drop a removable hard disk, there is no way to tell if the platters shattered, the heads are misaligned, or the drive just chooses to retire. I invariably would have to stop what is being done with one of the tape drives in a library, manually mount the dropped hard disk, and run a battery of thorough tests. Even then, I'd end up copying the data to a known good HDD and relegating the dropped one to forever languish in an offsite Iron Mountain tub.
As for dust and storage, that is why it is highly recommended to store tapes in the cases they come in. Even though the cases are not hermetically sealed, they do a great job at keeping dust on the outside, and not where it can affect the magnetic media inside.
Tapes are not perfect by any means . I remember one form of tape drive had the issue of sucking their leader tape (the piece that connects to the the leader of the cartridge), and being thus unusable until you got service out there, or you went and broke "warranty void if opened" seals in order to unwind it (which you don't want to do if you have a support contract).
As part of one way of doing backups, I backup a complete system, binaries and all. Yes,/bin/ls is sitting on a lot of repositories, but grabbing the binary and sticking it in place is a good amount of effort compared to a bare metal restore.
With a bare metal restore, I can boot from an image on a recovery CD, run the restore application, click "Restore all - overwrite anything existing". Then, after a time of some minutes to hours, I have a machine back to a known good state. If the machine has a local restore drive, it becomes even easier, because it becomes a matter of just ensuring that the destination drive is partitioned right, and letting the process run.
However this isn't to say you are wrong. In some cases, a reinstall and a copy of a home directory is just as good. Especially on some UNIX variants which have almost every application a person would need either on the OS media, and there are no config files which had to be extensively edited. In some cases, it might be faster to reinstall a box, run the package update tool (yum update, emerge, apt-get), and then copy back the data in/home. However, I end up finding that an image based restore is a lot faster in most cases.
The reverse can happen too. I copy large datasets to DVD+R from my backup program. If one of the DVDs fail (and I can easily have a 50 DVD set), then I lose a good chunk of files. Best case is always a mixed combination. You archive to DVDs, but you also have an alternative medium, such as a USB flash drive for smaller files, or an external USB hard disk for larger stuff.
If it has to have a flash BIOS for some reason, why does the flashing utility allow any image to go in without notice? Something like this should either require a signed or encrypted image that the flash utility decodes and decides is correct before putting it in. Maybe something simple as holding a distinct key sequence down on the keyboard while the utility pops up might be an alternative. This way at least the user has to be duped into knowingly flashing the keyboard, as opposed to a completely stealth compromise.
If I were making a keyboard with a flashable BIOS, rather than going the easy route and hiding a symmetric key on the chip would be eventually discovered, I'd use a SHA256 hash combined with an elliptic signing key to validate that a BIOS image was not tampered with before allowing it to be copied to the device. Yes, (barring someone breaking the public key crypto or obtaining the private key) someone could hack a particular keyboard to accept any flash image, but it would require physical access to the JTAG contacts on the device, and its well known that the game is over when an attacker obtains physical access to a machine anyway.
Even though AES is far from being truly broken, I wonder if it's time for NIST to start working on the AES2 spec. Maybe Serpent would be a good candidate because it was discussed that it had a larger margin of safety than Rijndael/AES.
As stated in TFA, attacks only get better and better, so every decade or so, maybe it would be time to consider another standard encryption algorithm. The reason DES lasted so long as an algorithm was that cryptography was not as vital to day to day operations as it is now, so a complete break would have been more of an academic excercise than one that would get the cryptographer financial gain. These days, if a blackhat does a break, or reduces the keyspace to a low level where brute forcing is possible, there are billions of dollars to be gained.
This is the solution that most BIOSes use for ATA hard disk locking. Due to the possibility for rogue programs putting on passwords onto hard disks, a feature was introduced to lock out any modifications to this functionality in drives other than on the BIOS level. This helps prevent OS level malware that would render drives unusable.
Flashing should be the same. Go into BIOS, insert a USB flash drive, load up the file, have the flashing utility do some sanity checks to ensure that the flash image is actually usable on that machine and motherboard, then finish the flashing. Of course, there should be a backup BIOS should power fail or something bad happen with the image that was flashed.
Maybe a centralized internal mirror server, perhaps two servers would be ideal for this type of work. One machine sits on a DMZ and does full time bit swapping, with the P2P client throttling bandwidth at peak hours. This machine then writes the shared files to a samba server which is used for the internal mirror. By bifurcating the duties, if the P2P server gets compromised, damage can be limited, especially if seeds are kept on a read only share.
Then employees can send in a ticket for a request to mirror some ISOs, say if the latest Slackware CD comes out.
With BitTorrent mainstream, there isn't much reason to bother with Kazaa, LimeWire, and other apps. BitTorrent isn't perfect, because finding a seeder is tough sometimes, but it is almost impossible to accidently share confidental data (accidently being the keyword here) unless someone manages to create a torrent, pass it to a tracker, start seeding, then pass the torrent file to a search engine while asleep.
Its not P2P in itself that is wrong. It is the use. The leaked information could have wound up on a website, blog, or FTP server, and I'm almost sure nobody would be saying that those technologies should be banned.
Devil's advocate here:
Even though piracy [1] is more akin to freeloading than theft, there are several cases where a company loses resources to pirates. One of them is bandwidth. Pirated copies grabbing updates and additional content cost the game publisher bandwidth (and bandwidth is almost always metered.) There are also pirates who tie up support lines. Both of these consume resources.
IMHO, I think the best thing to do is have a CD key system that comes into play for multiplayer (not LAN) play, and for downloading patches or additional DLC. When the game is at EOL after 3-4 years, patch the servers to allow any client to connect, not just the clients with valid CD keys, and patch the clients either with a universal key, or patch out the CD key algorithm completely. This way, should someone want to play the game in the future where it is sort of abandonware, it can be done with relative ease. Another idea is after the game EOLs, is to offer a final archive with every single thing in it, so the patch servers can be shut down, but anyone who wants the last build can go grab a self extracting file with that content in it.
Server-side this implementation of checking for updates is fairly simple. The client selects a server at random from its list (for load balancing reasons), sends a SOAP packet to the server over a SSL protected connection with the version of the game, the edition (standard, deluxe), a hash of the CD key [2], and the platform the game is on. The server hashes the CD key hash, checks that against what it has stored. If the second hash of the key is in a database, the server then redirects the client to a temporarily generated URL to obtain whatever additional content is offered.
[1]: Meaning "casual", non profit IP infringement. However, there are people who counterfeit games, with the box, packaging, logos, and media. Then they try to sell those to unwary customers. This type of piracy is actual theft because the offender gains cash and the game company loses a sale.
[2]: Valid CD keys should be tucked away in a database, and hashes used. This way should someone compromise the validation server, they won't be able to obtain live keys.
Part of the reason for this is that PHBs are more easily swayed by a smooth talking salesman selling a shiny new appliance that looks good in a rack, as opposed to a desperate IT manager who needs more headcount for admins.
Another reason is that employers in general are averse to hiring people right now. If some security appliance costs $200,000, it is a lot more attractive to the people with the purse strings than a $50,000/year admin. Mainly because of the philosophy of "machines don't get disgruntled" that some business schools teach.
In a recession, security is the last thing a business should cut.
The unemployment rate is high. This means that people who wouldn't think of things in normal times would turn to other means to supplement their income to keep a roof over their family's heads. So, someone who would normally give the finger to someone overseas asking for brief use of a username/password for $500 would happily give it in these times in order to keep the repo man away for another month.
More criminal organizations (domestic and overseas) realize there are profits to be made in capturing data stolen laptops for not just hardware, but the data on the machine. The data can be sold, or used to blackmail or extortion.
Employees are more likely to be disgruntled due to layoffs and cutbacks. So, vandalism and outright internal theft is on the rise.
There are a lot more regulations than before that make companies face shareholder lawsuits and corporate officers face prison time should a major breach occurs and a breach in process found.
Software CD keys are worth money, and a divulged volume CD key can force a company to re-buy every single license of a product as per EULA stipulations.
Outside attacks are more and more sophisticated as time goes on. To use an auto analogy, car companies are not using the same disc cylinder used on autos in the 1950s; they have moved to sidewinder cuts and "laser cut" keys. Same with security. A company has to keep abreast of new threats as a matter of life, just as CCTV cameras and bump-resistant locks on the doors are now the standard.
Thanks to Enron and other companies, and the knee-jerk regulations put into place after that like Sarbanes Oxley, a security person has to be familar with all these laws, like ISO 9000, ISO 10000, PCI-DSS.
Yes, you will be doing tons of TPM reports to ensure that the company is compliant, but if a company doesn't have the CYA papers, and something happens, there is a chance of prople facing prison time, and shareholders suing.
Its just how the game has changed. Locksmiths used to forge custom locks out of metal, now they use existing technology to suit a customer's needs with master key lists.
The trick is finding a security professional who knows this, and is able find the security tools that turn the company's policy, their security needs, and budget into implementable technology. A company can buy every single product sold in SC Magazine and the CISSP magazines. It won't do them much good because even the best security product will not give much protection if not implemented right.
For example, take a high grade HSM (hardware security module). If the admins of it allow everyone and their brother access to the signing key stored on it, or had the key flagged to be exported in an insecure manner, the security that the device provides is minimal.
Communication is key here. The reason why a security professional is a professional is that they have to have the knowledge to take what the client needs, their budget, the regulations the client is operating under, and the contracts of the client's customers and vendors. He or she needs to take that information and do two things: Buy the equipment, and configure it correctly. It's not just knowing all the technical stuff, but knowing how the company functions to put in a complete system that impacts productivity as minimal as possible, but yet provide protection against both known threats and unknown threats (zero days, unexpected threat vectors like compromised printers, etc.)
If there is a limited budget, a security pro has to get with the corporate officers and figure out where most likely attacks will come from. For example, a nontechnical call center has a high threat of physical theft of equipment, so they would be going with physical security, CCTV, enterprise systems to detect case intrusion events, and perhaps some form of encryption on all machines so if a machine or hard disk is stolen, licensed software and CD keys are protected. A credit card processor would be more concerned about network and perhaps social engineering attacks (although physical is still a concern).
I'm also curious not how much MSRP + TT&L, but how much in service costs? Part availability and price can be a major overall cost factor over a vehicle's lifetime.
Some questions I have, if this hits production:
Do mechanic shops have to have specialized equipment to work on this vehicle?
Do I have to wait days to weeks for a battery pack to come in? Hybrid batteries have a longer lifetime than the 1 year expected life of a laptop battery, but the lifetime is definitely finite until supercap technology is able to be mass produced.
How difficult and expensive will it be to get parts like bumpers, quarter panels, and other stuff that sometimes needs replaced due to drivers drunk or on cellphones?
How often does the vehicle need serviced? Newer cars only need taken in for oil changes pretty much. However, there are some older foreign cars which require a complete engine rebuild every 25,000 miles.
I always love seeing new car ideas, but for my main vehicle, I go for the tried, true, and commonly available, even though it may be boring.
The TPM boot process works off of "scan the next segment to be loaded and executed, pass the hash to the TPM". The TPM then keeps track of the hash process and when asked to unseal a key, either hands the key over if the cumulative hash matches, or refuses.
The TPM never is an active part of the boot process, it just sits there, accepts hashes, then either hands a key over, or doesn't.
Advantages of this in a FDE system:
Replacing the preboot authorization (PBA) code cannot be done without detection.
The TPM can be configured to ask for a password before unsealing the key. Too many wrong guesses, it will delay longer and longer.
The TPM is shipped disabled, and has to be explicitly enabled in BIOS.
Using a TPM for key storage means a machine boot unattended and can handle multiple users, but booting from other media is prevented. Say two people are sharing a laptop, neither could get at the other's files unless they have root/Administrator access.
Disadvantages:
The chip isn't hardened. A well heeled attacker who has access to a chip fab could probably disassemble the chip and pull out the sealed keys.
An unintended upgrade or change (enabling or disabling Hyper-V) without resealing the new code may result in the TPM not unsealing the key.
Not many machines have TPM chips.
Concerns about "trusted computing" being used for hardware-based DRM.
Maybe Microsoft could have this as part of the Windows Logo requirement. This could be implemented in two ways:
The first is actively hosting all updates. The problem with this is that it would require very large amounts of bandwidth, so there would have to be a revenue stream to Microsoft for them to be able to do this and remain profitable.
The second is having a pointer to the vendor's download URLs for a file. This is a lot easier, but still requires some added infrastructure and bandwidth. However, third party utilities like Secunia's PSI are able to hunt down and point out outdated/insecure versions, so it wouldn't be too onerous for a central switchboard for application vendors to have one place for update checking. Acresso (formerly Macrovision) has this functionality in their FLEXnet Connect product.
This is probably answered by a conventional PKI. Alice creates a key and sends it into the cloud. Alice then sends a note to Bob signed with her private key, and encrypted by his public key the information needed to pick up the key from the cloud (which bits to grab from which servers.) Bob then decrypts the note supposedly from Alice, validates her signature and then fishes the key material from the cloud.
To me, the cloud is a inserted between the two normal steps in the cypher process (the first being the public key crypto, the second being a symmetric encryption key for the message's contents. All public key encryption systems use a symmetric encryption system and only encrypt that key because of performance reasons. Symmetric encryption algorithms like AES can be thousands of times faster than the algorithms used for RSA or DSS.)
Vanish reminds me of the anonymous remailers of the mid 1990s where people made long chains to get a message from their machine to a destination. Any remailer in the chain that did not log messages, or destroyed the logs would make it impossible without a side channel attack [1] to obtain proof that it really was Alice sent an anonymous E-mail to Bob.
If there are not that many Vanish peer nodes, they can be compromised and instead of discarding key material on the expiration date, merely retain or actively archive it. Then an attacker would then grab the material from the nodes, piece together the expired key and be able to obtain the message without harassing Alice or Bob. However, if there are a lot of Vanish peer nodes, especially ones on laptops or or the transitory machines, there is a chance that not enough machines would be online for Bob to get a quorum of pieces to reconstruct the key.
Another attack, if an attacker had the ability to gain access to a lot of Vanish peer nodes, would be to find all the key pieces that expired on an exact date or time, then attempt to use those pieces to reconstruct a key. To foil this, the Vanish client would have to set the expiration to a minimum time, then add a random factor (could be small, could be large, perhaps 2-3 times the original delay) on each piece to prevent someone from doing this.
Vanish is a trade off. Alice gains assurance that an attacker has a timeout limit to factor Bob's key and get the key material from the Vanish cloud before it gets destroyed. However, what is deeply impacted is reliability. If the message is critical, there is a chance it may not be re-constructable due to lack of pieces available (similar to what happens if there is nobody able to seed a torrent, and the people on that torrent don't have enough pieces to completely reconstruct the file.)
[1]: In theory. In reality, if someone of great interest is suspected of sending anonymous E-mail by a well heeled organization, they can monitor the encrypted traffic they send out and that the person sent a mail to one anonymous remailer, then there was an encrypted E-mail packet traffic went to the second one in the chain via SMTP, until the end where the last node sends it in plaintext to the destination. Yes, it would take someone sophisticated enough to be wiretapping every single network link, but it can be done. Of course, remailers that at random time intervals send encrypted E-mail to other remailers with a random sized encrypted packet that is chucked would stop this attack, similar with remailers that hold mail for a random time before being passed to the next node.
One advantage I see is that after the Alice sends Bob the message and Bob has it stored, then the copies of the message floating around on the Internet become completely non-decryptable after the time limit has expired. Even if a third party manages to decode or obtain Bob's private key, it won't do them any good in obtaining the text; the attacker would have to attack either Alice or Bob's endpoint, which is a lot harder than just passively sifting stuff sitting on a server with unknown security.
Vanish does the same thing that cryptographic tokens do. Both limit the window of attack on something. Where a smart card would limit guesses of a key's PIN to 3-5, Vanish limits the time of attack of a message to 8-12 hours.
One quick addition:
Call your insurance company and see if you can get a rider for the netbook. Most rental plans and homeowner plans cover some computer equipment loss, but having explicit coverage of a computer against fire, theft, accidental microwaving, and other woes goes a long way to mitigate the loss of the hardware.
Theft still sucks since you are out your equipment, but at least you should be able to buy a new one when home with a good insurance plan. Always remember to get a police report if it does get stolen, because without it, you almost are certain to be not able to file a claim.
There are very lengthy discussions on the performance of full disk encryption. From what is usually stated, the performance overhead of a FDE program is very little, and not noticable by the average person.
It might come into play for a server doing large amounts of I/O to database container volumes, but for an OS partition, it shouldn't be noticable by most people, even on a lower power chipset like the Atom.
TrueCrypt is very good at this. The price is right too.
Two caveats:
If you can, carry a copy of the recovery CD with you. If for some reason, some program overwrites part of the boot track, you still have access to your data. Since TC stores the volume key on the boot track, if some utility or DRM system decides to write there (it shouldn't but a lot of them do to "individualize" the PC), it may make the TC volume completely unrecoverable without the recovery media. Each volume uses a different key, so you can't use a recovery CD from your desktop; you need to use the recovery media for that machine. This isn't just an issue with TC, other FDE (full disk encryption) programs might have parts overwritten, so its advisable to keep a recovery CD just in case.
Second, use a long passphrase. The days of using "passw0rd" or "letme1n" are long gone.
As for the dreaded inspection at airports, my advice would be to have two users (regardless of OS). The first user is one you are logged into when you pass the laptop to be inspected, and this user is a limited user (no access to sudo, not in the Administrators group). The second user is where you do all your work and have your home directory with your files. In most cases, someone inspecting stuff through an airport is more concerned that the laptop is a laptop and not anything nefarious.
If you want a "self destruct" feature, consider PGP or another FDE utility that supports cryptographic tokens like the Aladdin eToken. PGP has the ability to use a cryptographic token before booting, and if someone makes too many attempts at the smart card's password/PIN, it will either have a longer and longer delay between allowing attempts or lock out for good and permanently block access. TrueCrypt offers smart card support, but not for boot encryption, only mounted volumes. Of course, until you are completely convinced the cryptographic token is working, keep a backup passphrase so you can have access just in case.
For anti-theft protection, some laptops (don't know about netbooks) offer the ability to install Absolute Software's Lojack for Laptops into the BIOS. This way, should someone steal the netbook, completely zero out the drive and install a new copy of Windows, Lojack would silently install itself and phone home, allowing the stolen laptop to be traced by IP.
I use a similar system when offered by vendors. Blizzard has a keyfob, same with PayPal and eBay. Both of which are not technically SecurID, but OEM-ed VASCO tokens. My OpenID account on one site uses this keyfob as well.
What I wish for is someone to make a standard among the keyfobs, so regardless if someone has a SecurID card, a DigiPass Go, or a program that runs on a smartphone, they would be interchangable. Mainly so I don't need multiple keyfobs to authenticate to multiple sites, and it would be nice to buy a keyfob with selectable security features, be it merely pressing a button to see the 6 or 8 digit number, or more advanced measures like typing in a PIN, or swiping a fingerprint for three factor authentication (something you know, something you have, something you are.) Then take this standard for authentication and build it into all the popular OS logins, so the root password on a Linux box can be tied to one or more of these devices (so multiple people's keyfobs can authenticate).
Of course, it won't completely stop crime, but it will force malware writers to not just use passive keyloggers. Instead, they would be forced to go into more active man in the middle attacks against browsers (where the user is shown one thing while another action is being performed. IBM's ZTIC is the ideal solution for this.) This should be a lot more detectable though, as opposed to a keylogger that is just a driver hook away from silent operation.
All my machines went to IE8, even though I use Firefox as my browser of choice. Three reasons:
1: Security. You always want stuff that handles protentially hostile code as updated as possible. IE6 was made for the security threats of 2001. IE8 is made for far more current threats. Nothing is perfect, but IE has gotten a lot better as times have gone on. It has decent clickjacking protection, and seems to have had done a good job in standing up to NSS Labs's security tests.
2: Features. Auto-zapping all history and cache, and InPrivate browsing make it decently usable for those sites which require IE, or don't work well with Firefox.
3: Compatibility mode. There are some sites which still assume that everyone is going to be using IE6 for the forseeable future.
Most backup programs keep some type of checksum to check if files in a media set got damaged. However, if you want error correction, you likely will have to use an archiver like WinRAR, StuffIt Deluxe, QuickPAR, DVDisaster, or another utility that has this functionality built in. I have yet to encounter a backup app that has an option for Reed-Solomon ECC codes.
If I drop a tape on the shelf to the floor, I pick it up, check for physical damage, perhaps run a verify to be safe, and it becomes a non-issue. A DLT or LTO type of tape (media that isn't based around a consumer format) tape has to suffer heavy physical damage before data loss happens.
This is one of the biggest hard disk weaknesses. I drop a removable hard disk, there is no way to tell if the platters shattered, the heads are misaligned, or the drive just chooses to retire. I invariably would have to stop what is being done with one of the tape drives in a library, manually mount the dropped hard disk, and run a battery of thorough tests. Even then, I'd end up copying the data to a known good HDD and relegating the dropped one to forever languish in an offsite Iron Mountain tub.
As for dust and storage, that is why it is highly recommended to store tapes in the cases they come in. Even though the cases are not hermetically sealed, they do a great job at keeping dust on the outside, and not where it can affect the magnetic media inside.
Tapes are not perfect by any means . I remember one form of tape drive had the issue of sucking their leader tape (the piece that connects to the the leader of the cartridge), and being thus unusable until you got service out there, or you went and broke "warranty void if opened" seals in order to unwind it (which you don't want to do if you have a support contract).
As part of one way of doing backups, I backup a complete system, binaries and all. Yes, /bin/ls is sitting on a lot of repositories, but grabbing the binary and sticking it in place is a good amount of effort compared to a bare metal restore.
With a bare metal restore, I can boot from an image on a recovery CD, run the restore application, click "Restore all - overwrite anything existing". Then, after a time of some minutes to hours, I have a machine back to a known good state. If the machine has a local restore drive, it becomes even easier, because it becomes a matter of just ensuring that the destination drive is partitioned right, and letting the process run.
However this isn't to say you are wrong. In some cases, a reinstall and a copy of a home directory is just as good. Especially on some UNIX variants which have almost every application a person would need either on the OS media, and there are no config files which had to be extensively edited. In some cases, it might be faster to reinstall a box, run the package update tool (yum update, emerge, apt-get), and then copy back the data in /home. However, I end up finding that an image based restore is a lot faster in most cases.
The reverse can happen too. I copy large datasets to DVD+R from my backup program. If one of the DVDs fail (and I can easily have a 50 DVD set), then I lose a good chunk of files. Best case is always a mixed combination. You archive to DVDs, but you also have an alternative medium, such as a USB flash drive for smaller files, or an external USB hard disk for larger stuff.