What keeps the program from encrypting the whole backup repository, then demanding a key for that?
For backups, IMHO, the most secure way is to have a locked down backup server that runs some utility like Retrospect, Backup Exec, bru, or whatnot, and grabs the backups from machines via a dedicated client that supports encrypted connections. Then, should malware hit a client machine, it may cause a couple snapshots to be bad, but it won't toast the backup sets. Even a script that sshes in, and dumps the filesystems back via tar would be decent.
Only bad thing about backups -- only enterprise level tape drives have kept up with modern hard disk capacity, so for something that doesn't require piles of media, its about $3000 for something that can come close to backing up a modern box's hard disk without requiring multiple tapes. Disk capacity is levelling off, as its almost at the maximum aerial density that can be achieved in theory. If tape companies can even come close to that aerial density for tapes, they would have a winner.
The main reason for this is that it requires cash on the barrelhead for security certifications like FIPS, Common Criteria, etc.
RedHat and Novell have anted up to the table and can offer Linux desktops and servers in an industry that pretty much was Windows only, other than maybe a Solaris or AIX box here and there. Part of what people pay for when purchasing commercial support for RHCE or SUSE is the cost of this.
OBMac: MacOS 10 too has recently gotten FIPS certified, so that is another UNIX that is usable on the desktop where the certificates are needed for due diligence.
RedHat is great on servers, should something need changed, I can load the SRPM, make in-house source code changes, then have those stored separately from the original source so it can be documented come audit time what was changed in some program that needed customization on that level. To boot, with the binary RPM, all it takes is one simple command to push the change out to relevant machines via ssh and have those boxes install it.
Vista offers a spec to drive makers called the ReadyDrive, or a hybrid hard disk which combined some flash memory with a mechanical hard disk, to allow the drive to immediately write contents somewhere permanent, which boosts performance and allows the drive to schedule the optimum way to write out data as opposed to writing one chunk, waiting for the platter to spin around for another segment, then back to the first.
The only hybrid drive I see is an 80 gig seagate though, although there are likely more offerings.
Windows XP came with the Secure Audio Path "functionality" which meant that if a flag was checked on WM-DRM files, the file could only be played through audio drivers which were WHQL signed.
Windows ME also had this "functionality", different from Windows 98.
Pretty much, other than Secure Audio Path, activation in the non VLK editions, the Luna XP theme, improved EFS capability, more settings controllable in group policy, and the firewall, there wasn't that much changed. The kernel went from 5.0 in Windows 2000 to 5.1 in XP.
Volume Shadow copy is a way of freezing the volume's filesystem so a backup program was able to open files that are held open by other apps, such as database volumes, or Exchange mailboxes.
XP has a system snapshot feature, but that only saves images of executable files, as opposed to whole filesystem structures like Vista, Windows Server 2003, and Windows Server 2008.
The Previous Versions... feature came with Windows Server 2003, which had the ability to snapshot volumes, allowing one to restore deleted or corrupted stuff. This feature also came with Vista, and is very usable in Windows Server 2008.
So far, I have a Server 2008 box that has been up a month or so without anything bad... but I can't claim long uptimes due to patch reboots like I can with my Linux or BSD machines.:/
This is one ironic thing I find about Microsoft. Their client operating systems sometimes cause hair pulling, while they do quite well with their server stuff. I've gone from Windows NT Server 4.0 to Windows Server 2000, to 2003, now to 2008 as operating systems for my main machines (upgrading hardware every 2-3 years, and legal copies of the operating systems), and its been an overall positive experience.
Had I went the Windows 95, 98, ME, XP, then Vista, I'd probably be singing a different tune.
There are little things with Microsoft's server operating systems that make them nice to run. For example, if I drop in a new hard disk, MS's client operating systems will just assign it a letter. Windows Server 2003 and 2008 will wait until you go into the drive manager and assign the letter manually, so it doesn't mess things up. Probably the biggest thing is that MS's server operating systems install almost nothing by default, so anything present on the machine was explicitly installed there by choice.
The server operating systems also have some nice features. Its not Time Machine, but if I lose or corrupt a file, I can use the Previous Versions feature to pull an earlier version from a snapshot, each drive being snapshotted on a different schedule (my data drive being snapshotted almost hourly, the system volume less often, the music collection daily, etc.) Vista can do similar, but its all or nothing with their tool, rather than on an individual volume basis. Plus, its a given that server operating systems will be able to be logged in from remote while for that functionality on clients, it would require XP Pro, or Vista Business, Enterprise, or Ultimate.
This isn't to say that this functionality is in other operating systems, but so far, MS server OSes have lived up to the task of being solid and operable day and day out.
Methane works, but ethane is a lot easier on metal compounds (far less corrosive) and safer in general (although its still highly flammible). Drink ethanol (assuming not denatured), one gets drunk (or dies from alcohol poisoning). Drink methanol, and the optic nerve gets permanently polymerized by the by-products such as formic acid, which renders a person permanently blind.
Without violating thermaldynamic laws, I wonder how much electricity output this will add. I don't think it would double the current flow with 2-3 electrons popping out for each photon that strikes the array, but I know this should add a significant amount of efficiency.
I just hope all these advances, especially ones that make solar cells cheaper to manufacture go into production. There are huge chunks of the world that are lifeless desert, and would be perfect for large solar and wind arrays, assuming one could find a way to transport the generated electricity to cities without too much current loss. Perhaps some chemical reaction that pulls carbon from the air directly to make ethane, then another reaction that converts the ethane to ethanol to be piped to places that can burn the ethanol for electricity. Yes, the chemical reactions to pull carbon from the air, and get it into ethanol are wasteful, but for very long distance transfer of energy (100-200+ miles), it would be less wasteful to do that, than to use standard power transmission lines. Even though the ethanol electricity generating plants would be adding carbon into the air, it would be carbon neutral due to the carbon being extracted at the solar/wind site.
You are correct. Traces of RAM when its depowered doesn't plague just BitLocker, but it plagues all whole disk encryption utilities, be it TrueCrypt, PGP, and every one else. Other than a dedicated hard disk controller storing its keys in its own secure memory, the only way to protect against this is to mount encrypted volumes when needed, and dismount them the second one is finished. If on a laptop, use hibernation (which copies RAM to disk and turns the box off.) Hard disk utilities have responded by using obfuscation to hide the location of the encryption key in RAM and encrypt the key's values, but a sophisticated attacker can eventually decode it, provided all the RAM values they need are salvagable.
The key here is how common in the wild a cold RAM attack will be. I'm sure its more of a last resort for a forensics person than using a device that uses IEEE 1394 or another DMA bus to dump the contents of RAM. On BitLocker, one might be able to defend against insertion of a PCI card by enabling PCR #1 on the TPM to be checked for changes on boot (platform and motherboard configuration and data.) Of course, IEEE 1394 can be disabled.
Defending against physical access is a losing game as opposed to network access which one can just unplug a machine. However, its an attack vector that needs defense from more and more these days, as more crooks are realizing the value of data stored on machines.
I think eventually the large game companies will learn that intrusive DRM is not going to get them sales.
The carrot against intrusive DRM: Steam is raking money for Valve hand over fist where gamers can go to any PC, log onto their account and play what games they have purchased without issue. Another example is GalCiv 1 and 2 which have sold insane amounts of copies with the fact that they have zero copy protection on them and the quality of the gameplay is high.
The stick against intrusive DRM: There have been very intrusive DRM systems before, which resulted in games being boycotted, which caused game companies that love DRM to actually back down. Look at the fate of DIVX (not the codec, but the system that sold the locked silver discs around the time DVDs came out) for the fate of too intrusive DRM.
If a company wants to have antipiracy measures, have the game have decent network play and only allow one serial number at a time on the multiplayer network. Then people will buy new copies to play with friends. Of course, this won't stop the staunch pirates, but in reality, nobody stops those guys, and alienating customers (especially in this collapsing economy where people are hard-pressed to pony up for games unless they know they will be good) with intrusive copy-protection won't be to anyone's benefit.
If a company is so paranoid about their IP, that they must have a really intrusive system, they can just write for consoles.
I have a feeling TPMs on motherboards will still be something one has to explicitly search out in a couple years, for the same reason that most motherboards don't have onboard fiber channel connectors -- outside of businesses, there isn't much demand for TPM functionality, so motherboard makers will save the $10 or so for the Wave Systems or Infineon chip and only put it on motherboards slated for corporate use.
The TPM chip that comes in computers is totally different than the hardware chips, curtained memory, and super-root apps that were in Palladium. In the NGSCB, the hardware had an active role of maintaining I/O, and managing memory.
The current version of the TPM is not in the active path at all. Fundamentally, all a TPM 1.2 chip is, is a smart card that is attached to the motherboard. The only difference between it and an Aladdin eToken that is plugged into a USB port are two things. First, are the platform configuration registers, which you manually have to put data into, and second the TPM is resettable from the BIOS screen.
TPM chips, as per the TCG 1.2 spec ship disabled and deactivated, and the user of the machine has to go into BIOS to enable the chip and take physical ownership. Otherwise, it can't be accessed by the machine in any way.
Motherboards TPM chips are rare to find. For a server I built that is to be able to boot unattended, but have all its volumes encrypted using BitLocker, I had to chase down stats on Intel's website and compare them to currently selling motherboards, then cross-reference them to make sure there was an actual chip, and not just BIOS headers.
The Atari founder is quite wrong. Using the TPM won't give much protection from pirates. We've already hard hardware devices encrypting software for decades -- the good old fashioned dongles.
Second, no modern OS ships with a trusted, sealed OS path that is forever static and can be signed from the OS company and passed directly to the TPM like console operating systems are done. Windows Server 2008 has different drivers load for RAID and other low level devices which vary widely party. For example, If you install a new role like Hyper-V on Windows Server 2008, you have to disable and re-enable BitLocker, or the OS path won't be the same. Bitlocker doesn't use OS signatures from a central source, when its enabled, it does its own signing and sealing of the boot path and other user selectable data (BIOS settings, NTFS stats, MBR, partition table.)
The Atari founder assumes too much. PCs are not consoles where having a chip on a static OS and hardware can provide adequate protection. For the TPM chip on PCs to be used for piracy protection, every gaming machine would have to have one physically present, enabled, activated, and ownership taken in the OS the chip is running under, the OS would have to have a static low level kernel that never changes from machine to machine regardless of CPU or devices installed, which for a PC is virtually impossible.
TPM chips also have been emulated too. All it takes is one person to be able to bypass the protection, and the game is cracked.
All and all, in my personal experience, TPM chips are a good thing, especially with BitLocker. A server can boot unattended but still possess hard disk encryption so someone who gets physical access to the box can't just boot a CD and copy off the server's contents. I'd recommend this for co-loc boxes, especially in these times where thieves are learning that a data center heist can net far more cash in information to sell on the ID theft market (or just plain old extortion) than a bank robbery would haul in.
A laptop owned by a company bound by corporate regs can use BitLocker or PGP to ensure the laptop has hard disk encryption, but doesn't have any more passwords the user has to remember. Finally, someone can use BitLocker + a PIN, so if someone steals a laptop or machine, they only have 3-5 guesses before the TPM refused entries or starts adding substantial delays between password guesses.
Of course, there are hard disk encryption programs with pre-boot authentication (TrueCrypt, PGP, etc.), but BitLocker is the only one that offers the feature of booting a machine completely unattended, but yet remain secure. Of course, one can have an OS boot then manually mount encrypted volumes, but BitLocker removes the hassle of this, especially if the machine is in a remote location where no admins would be present, and a network connection is not feasible.
The TPM chip in its current form is a security asset (IMHO). It, in its current incarnation, would provide little help for new DRM or antipiracy schemes.
I don't think the company can prohibit the co-worker contact, but they can try to get a judge to give a peace bond (restraining order) to keep someone off the corporate premises.
Maybe its different with assaults, but in most places, a peace bond requires the person who is getting barred to be served, and have to attend a hearing so he or she can appeal or perhaps quash the proposed restraining order.
I've seen variants on this. Best one so far was a business who would lock people's badge access and other accountswhen terminating people when they went out for lunch, and on returning, be told they would nailed for trespassing if they didn't leave the premises immediately, and then escorted out to the door by a security guard just looking for an excuse to use his tazer or Kimber JPX (a high powered pepper spray squirt gun). Terminated employees didn't even get a box with their stuff on the desk -- it was shipped parcel post to their address, and it was argued that stuff that was interesting on people's desks didn't make it into the box that was shipped to the address.
Not just Comcast, but a lot of companies do this, where all vacation time is dumped come January 1 of the next year, and vacation time can't be converted to pay.
I've worked at a couple places that always have the "Christmas Exodus" where the company for the most part shuts down most of December as people get their vacation days in while they can, other than the finance people who are running themselves ragged with EOY stuff.
I've worked at companies where they didn't have a difference between terminated employees, and employees who were leaving on their own accord. Both were put under the same guidelines, so an employee who might be retiring, moving to a contractor position, or moving to a completely different position at another company, with plenty of notice given will get the same bum rush out the door as someone who was fired for lighting farts in the executive washroom.
I think there is/was a difference between DoD work with classified+ information and private companies.
Until recently, it was assumed that even if it was known that a person was quitting in a job that required a security clearance, they would not be divulging any of the stuff they worked with for any reasons whatsoever, as there are stiff criminal penalties for this.
In private companies, they have an NDA with relatively minor civil consequences, and information in a company, though considered secret to the corporate officers is not truly secret in the classified sense, but "merely" considered a trade secret. So companies are swift to react to someone who they just find who is bailing on them, but still has access to the crown jewels, regardless of job function or whatnot. Its a pure knee-jerk reaction. Even with an NDA, companies go into panic mode when one of their high security employees leaves because they are afraid of stuff being learned by "osmosis" about their secret chocolate chip recipes by the competition.
Good point. All malware needs is access to a TCP stack on a machine with a decent connection to do most of what it needs to do, be it syncing up to a master bot server to accept new commands, or scanning for documents and copying them to another server. The only thing malware can't do in user mode is log keystrokes (unless its X11 and the app makes a transparent window that fits the full screen.)
This brings up another concern. Even though Charter/Phorm is not being malevolent, just greedy... what happens if their proxy server/ad server gets hijacked or compromised? Such a server would make a big target for thieves because of the gains.
Should something that injects ads gets compromised, a malware distributer now would have unfettered access to every single Charter subscriber. A compromised ad server could be done in such a way where only a relatively few people at random would get exposed to zero day exploit code.
What was intended as a money stream would make an identity theft ring very happy, with not just being able to add new members to botnets, but to log traffic of subscribers for either use for ID theft, or perhaps extortion.
What is ironic is that damage caused by an ad injection server would be immediately blamed on the destination website, and in a court of law, criminal charges can be pressed and likely made to stick (because juries won't consider ad injector "services" as reasonable doubt.) Civil charges almost certainly will be able to be won. A compromised ad injecting server could easy go for months if not longer, escaping detection, as there would be zero proof that it was the ad injection "service" that did this.
Again, I posted earlier about having some facility to sign Web pages without needing the overhead of full SSL... perhaps someone should look into this, so high volume websites can still serve pages with little overhead, but offer immediate detection if the page is modified in transit.
For web content that doesn't need to go over SSL/TLS, I wonder about some way of having webservers sign the HTML of the get request with their SSL key, and cache that signature, so subsequent requests of that HTML page have almost no overhead incurred.
Then, on high volume servers that are not needing the security of SSL, the core HTML page that gets to the client can be verified (using the client's CPU time) if it was modified in transit, without the server needing to spend the CPU time for SSL's overhead. If the HTML doesn't match, then offer the user a mechanism to browse the site entirely using SSL.
The only issue is for dynamic content that can't be cached, this will add a cryptographic signing step for each page.
An example:
Someone browses www.foo.com the webserver at foo.com grabs index.html, signs it with www.foo.com's SSL key, saves the signature in a cache that is reset if someone legitimately edits index.html on the server, then sends the web browser index.html and after that, index.html's signature, perhaps in OpenPGP format. After the first signing, all the webserver is doing is sending two files (index.html and the cached signature.) The web browser compared the received index.html to the signature, and alerts the user if it was tampered with.
As for my stuff, for low volume web servers such as my home domain, I just automatically redirect the user to the SSL server, because that stops this problem cold. If an ISP is able to intercept SSL traffic, (especially with an EV certificate), they are so advanced at crypto, they deserve to be able to insert ads.
I have a feeling that it will only be a matter of time before not just ISPs that people are subscribed on, but large volume peering nodes will try their hand at inserting ads, so might as well just force as much traffic to SSL whenever possible now, although for high volume sites, this is far easier said than done.
Yes, you can tell the BSA to leave. However, either later that day or next business day, they will be back with two armed deputies and a motion of discovery, subpoenaing every business record you have, down to the the odor and sound of employee flatulence in cubicals.
They will then look at your invoices. The BSA doesn't care about certificates or license keys. They want to see invoices of how many license keys are with what product. And having fewer license keys than products in use is a bad thing... they will have litigation pending against the business within hours if you don't.
I've dealt with the BSA before when working for a business, and a disgruntled ex-employee made a bogus piracy report to them. If you are able to reasonably cough up what is present and installed softwarewise on machines, then show them a file cabinet of invoices, they will leave you alone in the future and likely not bother your business again, even if other people scream bloody murder about piracy.
The trick is, if you run a business, keep your books balanced, which is important for any business out there.
What my concern is with sites which demand so many registration details... what happens with that info, and where is it stored?
If this guy wants paid registration, he should just say so and have that, where people cough up $10 a year or something for access to the site's contents.
Instead, perhaps he should do what a lot of websites do -- require either a "non-free" E-mail address, or manual approving for a user account if its a Yahoo/Hotmail/Gmail account. This is not a 100% measure, as there are lots of people who pay for their Yahoo or Hotmail accounts, but its a measure good enough to do what this guy wants. Should a non-free provider start having abuse problems, add that domain on the "manual approve" list, and call it done.
Cubase and the plugins (called VST plugins) which are sold at additional cost use a dongle. The replacement policy on a lost or stolen dongle by Steinberg is pretty clear -- there is none. You re-buy their stuff, and you re-purchase any and all VST modules.
This is why once I graduate college and can afford it, I would either use a Mac and Logic Studio, or a PC and use Sony's Acid Pro offering. Neither product has hardware which can be stolen at a gig (other than the PC itself), and both do everything Cubase does without the hassles of hardware dongles which (as previously stated) are last decade.
It used to be there was a perception that server rooms were considered secure. In the past, the access card to the door, after one got past a front desk and the sign in sheet gave enough security show that people trusted colocs with their expensive equipment.
Now that the economy is collapsing, a person at the front desk, an electronic lock on the NOC door, and a key lock on the rack door doesn't cut it anymore. The thugs who used to carjack are now noticing that they can make lots of money, not just on the stolen hardware, but on the contents which can be sold to offshore identity thieves or blackmailers for a hefty profit. Coloc operators now have to factor in armed and forcible intrusions.
As with most security items, this problem sort can be mitigated, but it will take several layers. First, the low-res time lapse cameras have to go that most places use as surveillance. I'd love to see 1024p, but the best around seems to be 480 or 540p for this type of duty. Of course, the footage has to go to a place where the local staff has no access to, preferably to an offsite RAID array.
Second, silent/holdup alarms are needed, and stuff more sophisticated than the panic button under the desk. Preferably on door locks, combine a card reader with a PIN, and a duress code, so an employee can open the door, but yet have help on the way.
Finally, and this is something that is a new field to computing essentially. Servers have to have some defense against console attacks now built into the machine itself. In days past, having servers in the glass room was good enough. Now, because physical access is not a deterrence, servers need to have encryption on their hard disks and arrays, encryption that keeps thieves from accessing data, but (and this is the hard part) doesn't interfere with the server's availability. As of now, there is only one solution out there that allows for encryption of a server's volumes, but still allows a server to boot. Bitlocker + a TPM 1.2 chip.
Bitlocker is the only solution I know of that will let a server boot unattended in a remote location where nobody on site can provide a passphrase to start the machine with normal whole disk encryption, but still will protect the contents on the data volumes against theft or access by booting from another OS. Yes, one can have a smart card that auto-decrypts a key, but one thing BitLocker provides with the TPM hardware is that the code read during boot has not been changed, so someone can't just create a new MBR to compromise the OS.
Yes, the TPM chip has its controversy, but in this context there is no arguing that it is performing a needed function. I'd like to see its functionality combined perhaps with BIOS settings, an intrusion sensor, and perhaps an integral GPS sensor in the machine. Should the machine's BIOS get tampered with, the case opened, or the machine moved by more than a couple hundred feet, the TPM would not give up the key to decrypt the volumes. Of course, the volumes can be unlocked with the manual key or number later on(which is kept in a different location.)
As time goes on, perhaps one item that can be added to servers is a fiber optic security cable with a standard interface. I know universities that use this type of system and should the cable be cut without the right code being inputted, a silent alarm sounds and the university's PD heads over. I think this functionality might be something to add to servers where if the cable is disconnected without explicit setting by a privileged user, the machine would immediately shut down, wipe its RAM, and have the TPM chip not allow access. This would allow servers to be maintained, but if someone tries removing them, the thieves end up with hardware and no data.
Its a sad fact of life, but as time goes on, IBM, Sun, HP, and other high end server makers will have to build in security measures that protect console security, allowing normal administrative tasks, but protecting data against physical removal of equipment, even by authorized people due to armed robberies.
On gigs, its not uncommon for people to try to rip off the USB dongles which are used as license keys for VST plugins and various music software. This sucks because it might cause a band not to be able to complete their set if they don't have backup tracks.
Protecting VST keys for desktop or rackmounts is fairly easy -- you have a USB card with an internal port and plug your VST license dongle into that, leaving that inside the machine. However, for laptops its harder and quite easy for someone to walk up, grab the dongle and run off.
Slashdot Mirror
What keeps the program from encrypting the whole backup repository, then demanding a key for that?
For backups, IMHO, the most secure way is to have a locked down backup server that runs some utility like Retrospect, Backup Exec, bru, or whatnot, and grabs the backups from machines via a dedicated client that supports encrypted connections. Then, should malware hit a client machine, it may cause a couple snapshots to be bad, but it won't toast the backup sets. Even a script that sshes in, and dumps the filesystems back via tar would be decent.
Only bad thing about backups -- only enterprise level tape drives have kept up with modern hard disk capacity, so for something that doesn't require piles of media, its about $3000 for something that can come close to backing up a modern box's hard disk without requiring multiple tapes. Disk capacity is levelling off, as its almost at the maximum aerial density that can be achieved in theory. If tape companies can even come close to that aerial density for tapes, they would have a winner.
The main reason for this is that it requires cash on the barrelhead for security certifications like FIPS, Common Criteria, etc.
RedHat and Novell have anted up to the table and can offer Linux desktops and servers in an industry that pretty much was Windows only, other than maybe a Solaris or AIX box here and there. Part of what people pay for when purchasing commercial support for RHCE or SUSE is the cost of this.
OBMac: MacOS 10 too has recently gotten FIPS certified, so that is another UNIX that is usable on the desktop where the certificates are needed for due diligence.
RedHat is great on servers, should something need changed, I can load the SRPM, make in-house source code changes, then have those stored separately from the original source so it can be documented come audit time what was changed in some program that needed customization on that level. To boot, with the binary RPM, all it takes is one simple command to push the change out to relevant machines via ssh and have those boxes install it.
Vista offers a spec to drive makers called the ReadyDrive, or a hybrid hard disk which combined some flash memory with a mechanical hard disk, to allow the drive to immediately write contents somewhere permanent, which boosts performance and allows the drive to schedule the optimum way to write out data as opposed to writing one chunk, waiting for the platter to spin around for another segment, then back to the first.
The only hybrid drive I see is an 80 gig seagate though, although there are likely more offerings.
Windows XP came with the Secure Audio Path "functionality" which meant that if a flag was checked on WM-DRM files, the file could only be played through audio drivers which were WHQL signed.
Windows ME also had this "functionality", different from Windows 98.
Pretty much, other than Secure Audio Path, activation in the non VLK editions, the Luna XP theme, improved EFS capability, more settings controllable in group policy, and the firewall, there wasn't that much changed. The kernel went from 5.0 in Windows 2000 to 5.1 in XP.
Volume Shadow copy is a way of freezing the volume's filesystem so a backup program was able to open files that are held open by other apps, such as database volumes, or Exchange mailboxes.
XP has a system snapshot feature, but that only saves images of executable files, as opposed to whole filesystem structures like Vista, Windows Server 2003, and Windows Server 2008.
The Previous Versions... feature came with Windows Server 2003, which had the ability to snapshot volumes, allowing one to restore deleted or corrupted stuff. This feature also came with Vista, and is very usable in Windows Server 2008.
So far, I have a Server 2008 box that has been up a month or so without anything bad... but I can't claim long uptimes due to patch reboots like I can with my Linux or BSD machines. :/
This is one ironic thing I find about Microsoft. Their client operating systems sometimes cause hair pulling, while they do quite well with their server stuff. I've gone from Windows NT Server 4.0 to Windows Server 2000, to 2003, now to 2008 as operating systems for my main machines (upgrading hardware every 2-3 years, and legal copies of the operating systems), and its been an overall positive experience.
Had I went the Windows 95, 98, ME, XP, then Vista, I'd probably be singing a different tune.
There are little things with Microsoft's server operating systems that make them nice to run. For example, if I drop in a new hard disk, MS's client operating systems will just assign it a letter. Windows Server 2003 and 2008 will wait until you go into the drive manager and assign the letter manually, so it doesn't mess things up. Probably the biggest thing is that MS's server operating systems install almost nothing by default, so anything present on the machine was explicitly installed there by choice.
The server operating systems also have some nice features. Its not Time Machine, but if I lose or corrupt a file, I can use the Previous Versions feature to pull an earlier version from a snapshot, each drive being snapshotted on a different schedule (my data drive being snapshotted almost hourly, the system volume less often, the music collection daily, etc.) Vista can do similar, but its all or nothing with their tool, rather than on an individual volume basis. Plus, its a given that server operating systems will be able to be logged in from remote while for that functionality on clients, it would require XP Pro, or Vista Business, Enterprise, or Ultimate.
This isn't to say that this functionality is in other operating systems, but so far, MS server OSes have lived up to the task of being solid and operable day and day out.
Methane works, but ethane is a lot easier on metal compounds (far less corrosive) and safer in general (although its still highly flammible). Drink ethanol (assuming not denatured), one gets drunk (or dies from alcohol poisoning). Drink methanol, and the optic nerve gets permanently polymerized by the by-products such as formic acid, which renders a person permanently blind.
Without violating thermaldynamic laws, I wonder how much electricity output this will add. I don't think it would double the current flow with 2-3 electrons popping out for each photon that strikes the array, but I know this should add a significant amount of efficiency.
I just hope all these advances, especially ones that make solar cells cheaper to manufacture go into production. There are huge chunks of the world that are lifeless desert, and would be perfect for large solar and wind arrays, assuming one could find a way to transport the generated electricity to cities without too much current loss. Perhaps some chemical reaction that pulls carbon from the air directly to make ethane, then another reaction that converts the ethane to ethanol to be piped to places that can burn the ethanol for electricity. Yes, the chemical reactions to pull carbon from the air, and get it into ethanol are wasteful, but for very long distance transfer of energy (100-200+ miles), it would be less wasteful to do that, than to use standard power transmission lines. Even though the ethanol electricity generating plants would be adding carbon into the air, it would be carbon neutral due to the carbon being extracted at the solar/wind site.
You are correct. Traces of RAM when its depowered doesn't plague just BitLocker, but it plagues all whole disk encryption utilities, be it TrueCrypt, PGP, and every one else. Other than a dedicated hard disk controller storing its keys in its own secure memory, the only way to protect against this is to mount encrypted volumes when needed, and dismount them the second one is finished. If on a laptop, use hibernation (which copies RAM to disk and turns the box off.) Hard disk utilities have responded by using obfuscation to hide the location of the encryption key in RAM and encrypt the key's values, but a sophisticated attacker can eventually decode it, provided all the RAM values they need are salvagable.
The key here is how common in the wild a cold RAM attack will be. I'm sure its more of a last resort for a forensics person than using a device that uses IEEE 1394 or another DMA bus to dump the contents of RAM. On BitLocker, one might be able to defend against insertion of a PCI card by enabling PCR #1 on the TPM to be checked for changes on boot (platform and motherboard configuration and data.) Of course, IEEE 1394 can be disabled.
Defending against physical access is a losing game as opposed to network access which one can just unplug a machine. However, its an attack vector that needs defense from more and more these days, as more crooks are realizing the value of data stored on machines.
I think eventually the large game companies will learn that intrusive DRM is not going to get them sales.
The carrot against intrusive DRM: Steam is raking money for Valve hand over fist where gamers can go to any PC, log onto their account and play what games they have purchased without issue. Another example is GalCiv 1 and 2 which have sold insane amounts of copies with the fact that they have zero copy protection on them and the quality of the gameplay is high.
The stick against intrusive DRM: There have been very intrusive DRM systems before, which resulted in games being boycotted, which caused game companies that love DRM to actually back down. Look at the fate of DIVX (not the codec, but the system that sold the locked silver discs around the time DVDs came out) for the fate of too intrusive DRM.
If a company wants to have antipiracy measures, have the game have decent network play and only allow one serial number at a time on the multiplayer network. Then people will buy new copies to play with friends. Of course, this won't stop the staunch pirates, but in reality, nobody stops those guys, and alienating customers (especially in this collapsing economy where people are hard-pressed to pony up for games unless they know they will be good) with intrusive copy-protection won't be to anyone's benefit.
If a company is so paranoid about their IP, that they must have a really intrusive system, they can just write for consoles.
I have a feeling TPMs on motherboards will still be something one has to explicitly search out in a couple years, for the same reason that most motherboards don't have onboard fiber channel connectors -- outside of businesses, there isn't much demand for TPM functionality, so motherboard makers will save the $10 or so for the Wave Systems or Infineon chip and only put it on motherboards slated for corporate use.
The TPM chip that comes in computers is totally different than the hardware chips, curtained memory, and super-root apps that were in Palladium. In the NGSCB, the hardware had an active role of maintaining I/O, and managing memory.
The current version of the TPM is not in the active path at all. Fundamentally, all a TPM 1.2 chip is, is a smart card that is attached to the motherboard. The only difference between it and an Aladdin eToken that is plugged into a USB port are two things. First, are the platform configuration registers, which you manually have to put data into, and second the TPM is resettable from the BIOS screen.
TPM chips, as per the TCG 1.2 spec ship disabled and deactivated, and the user of the machine has to go into BIOS to enable the chip and take physical ownership. Otherwise, it can't be accessed by the machine in any way.
Motherboards TPM chips are rare to find. For a server I built that is to be able to boot unattended, but have all its volumes encrypted using BitLocker, I had to chase down stats on Intel's website and compare them to currently selling motherboards, then cross-reference them to make sure there was an actual chip, and not just BIOS headers.
The Atari founder is quite wrong. Using the TPM won't give much protection from pirates. We've already hard hardware devices encrypting software for decades -- the good old fashioned dongles.
Second, no modern OS ships with a trusted, sealed OS path that is forever static and can be signed from the OS company and passed directly to the TPM like console operating systems are done. Windows Server 2008 has different drivers load for RAID and other low level devices which vary widely party. For example, If you install a new role like Hyper-V on Windows Server 2008, you have to disable and re-enable BitLocker, or the OS path won't be the same. Bitlocker doesn't use OS signatures from a central source, when its enabled, it does its own signing and sealing of the boot path and other user selectable data (BIOS settings, NTFS stats, MBR, partition table.)
The Atari founder assumes too much. PCs are not consoles where having a chip on a static OS and hardware can provide adequate protection. For the TPM chip on PCs to be used for piracy protection, every gaming machine would have to have one physically present, enabled, activated, and ownership taken in the OS the chip is running under, the OS would have to have a static low level kernel that never changes from machine to machine regardless of CPU or devices installed, which for a PC is virtually impossible.
TPM chips also have been emulated too. All it takes is one person to be able to bypass the protection, and the game is cracked.
All and all, in my personal experience, TPM chips are a good thing, especially with BitLocker. A server can boot unattended but still possess hard disk encryption so someone who gets physical access to the box can't just boot a CD and copy off the server's contents. I'd recommend this for co-loc boxes, especially in these times where thieves are learning that a data center heist can net far more cash in information to sell on the ID theft market (or just plain old extortion) than a bank robbery would haul in.
A laptop owned by a company bound by corporate regs can use BitLocker or PGP to ensure the laptop has hard disk encryption, but doesn't have any more passwords the user has to remember. Finally, someone can use BitLocker + a PIN, so if someone steals a laptop or machine, they only have 3-5 guesses before the TPM refused entries or starts adding substantial delays between password guesses.
Of course, there are hard disk encryption programs with pre-boot authentication (TrueCrypt, PGP, etc.), but BitLocker is the only one that offers the feature of booting a machine completely unattended, but yet remain secure. Of course, one can have an OS boot then manually mount encrypted volumes, but BitLocker removes the hassle of this, especially if the machine is in a remote location where no admins would be present, and a network connection is not feasible.
The TPM chip in its current form is a security asset (IMHO). It, in its current incarnation, would provide little help for new DRM or antipiracy schemes.
I don't think the company can prohibit the co-worker contact, but they can try to get a judge to give a peace bond (restraining order) to keep someone off the corporate premises.
Maybe its different with assaults, but in most places, a peace bond requires the person who is getting barred to be served, and have to attend a hearing so he or she can appeal or perhaps quash the proposed restraining order.
I've seen variants on this. Best one so far was a business who would lock people's badge access and other accountswhen terminating people when they went out for lunch, and on returning, be told they would nailed for trespassing if they didn't leave the premises immediately, and then escorted out to the door by a security guard just looking for an excuse to use his tazer or Kimber JPX (a high powered pepper spray squirt gun). Terminated employees didn't even get a box with their stuff on the desk -- it was shipped parcel post to their address, and it was argued that stuff that was interesting on people's desks didn't make it into the box that was shipped to the address.
Not just Comcast, but a lot of companies do this, where all vacation time is dumped come January 1 of the next year, and vacation time can't be converted to pay.
I've worked at a couple places that always have the "Christmas Exodus" where the company for the most part shuts down most of December as people get their vacation days in while they can, other than the finance people who are running themselves ragged with EOY stuff.
I've worked at companies where they didn't have a difference between terminated employees, and employees who were leaving on their own accord. Both were put under the same guidelines, so an employee who might be retiring, moving to a contractor position, or moving to a completely different position at another company, with plenty of notice given will get the same bum rush out the door as someone who was fired for lighting farts in the executive washroom.
I think there is/was a difference between DoD work with classified+ information and private companies.
Until recently, it was assumed that even if it was known that a person was quitting in a job that required a security clearance, they would not be divulging any of the stuff they worked with for any reasons whatsoever, as there are stiff criminal penalties for this.
In private companies, they have an NDA with relatively minor civil consequences, and information in a company, though considered secret to the corporate officers is not truly secret in the classified sense, but "merely" considered a trade secret. So companies are swift to react to someone who they just find who is bailing on them, but still has access to the crown jewels, regardless of job function or whatnot. Its a pure knee-jerk reaction. Even with an NDA, companies go into panic mode when one of their high security employees leaves because they are afraid of stuff being learned by "osmosis" about their secret chocolate chip recipes by the competition.
Good point. All malware needs is access to a TCP stack on a machine with a decent connection to do most of what it needs to do, be it syncing up to a master bot server to accept new commands, or scanning for documents and copying them to another server. The only thing malware can't do in user mode is log keystrokes (unless its X11 and the app makes a transparent window that fits the full screen.)
This brings up another concern. Even though Charter/Phorm is not being malevolent, just greedy... what happens if their proxy server/ad server gets hijacked or compromised? Such a server would make a big target for thieves because of the gains.
Should something that injects ads gets compromised, a malware distributer now would have unfettered access to every single Charter subscriber. A compromised ad server could be done in such a way where only a relatively few people at random would get exposed to zero day exploit code.
What was intended as a money stream would make an identity theft ring very happy, with not just being able to add new members to botnets, but to log traffic of subscribers for either use for ID theft, or perhaps extortion.
What is ironic is that damage caused by an ad injection server would be immediately blamed on the destination website, and in a court of law, criminal charges can be pressed and likely made to stick (because juries won't consider ad injector "services" as reasonable doubt.) Civil charges almost certainly will be able to be won. A compromised ad injecting server could easy go for months if not longer, escaping detection, as there would be zero proof that it was the ad injection "service" that did this.
Again, I posted earlier about having some facility to sign Web pages without needing the overhead of full SSL... perhaps someone should look into this, so high volume websites can still serve pages with little overhead, but offer immediate detection if the page is modified in transit.
For web content that doesn't need to go over SSL/TLS, I wonder about some way of having webservers sign the HTML of the get request with their SSL key, and cache that signature, so subsequent requests of that HTML page have almost no overhead incurred.
Then, on high volume servers that are not needing the security of SSL, the core HTML page that gets to the client can be verified (using the client's CPU time) if it was modified in transit, without the server needing to spend the CPU time for SSL's overhead. If the HTML doesn't match, then offer the user a mechanism to browse the site entirely using SSL.
The only issue is for dynamic content that can't be cached, this will add a cryptographic signing step for each page.
An example:
Someone browses www.foo.com
the webserver at foo.com grabs index.html, signs it with www.foo.com's SSL key, saves the signature in a cache that is reset if someone legitimately edits index.html on the server, then sends the web browser index.html and after that, index.html's signature, perhaps in OpenPGP format. After the first signing, all the webserver is doing is sending two files (index.html and the cached signature.)
The web browser compared the received index.html to the signature, and alerts the user if it was tampered with.
As for my stuff, for low volume web servers such as my home domain, I just automatically redirect the user to the SSL server, because that stops this problem cold. If an ISP is able to intercept SSL traffic, (especially with an EV certificate), they are so advanced at crypto, they deserve to be able to insert ads.
I have a feeling that it will only be a matter of time before not just ISPs that people are subscribed on, but large volume peering nodes will try their hand at inserting ads, so might as well just force as much traffic to SSL whenever possible now, although for high volume sites, this is far easier said than done.
Yes, you can tell the BSA to leave. However, either later that day or next business day, they will be back with two armed deputies and a motion of discovery, subpoenaing every business record you have, down to the the odor and sound of employee flatulence in cubicals.
They will then look at your invoices. The BSA doesn't care about certificates or license keys. They want to see invoices of how many license keys are with what product. And having fewer license keys than products in use is a bad thing... they will have litigation pending against the business within hours if you don't.
I've dealt with the BSA before when working for a business, and a disgruntled ex-employee made a bogus piracy report to them. If you are able to reasonably cough up what is present and installed softwarewise on machines, then show them a file cabinet of invoices, they will leave you alone in the future and likely not bother your business again, even if other people scream bloody murder about piracy.
The trick is, if you run a business, keep your books balanced, which is important for any business out there.
What my concern is with sites which demand so many registration details... what happens with that info, and where is it stored?
If this guy wants paid registration, he should just say so and have that, where people cough up $10 a year or something for access to the site's contents.
Instead, perhaps he should do what a lot of websites do -- require either a "non-free" E-mail address, or manual approving for a user account if its a Yahoo/Hotmail/Gmail account. This is not a 100% measure, as there are lots of people who pay for their Yahoo or Hotmail accounts, but its a measure good enough to do what this guy wants. Should a non-free provider start having abuse problems, add that domain on the "manual approve" list, and call it done.
Cubase and the plugins (called VST plugins) which are sold at additional cost use a dongle. The replacement policy on a lost or stolen dongle by Steinberg is pretty clear -- there is none. You re-buy their stuff, and you re-purchase any and all VST modules.
This is why once I graduate college and can afford it, I would either use a Mac and Logic Studio, or a PC and use Sony's Acid Pro offering. Neither product has hardware which can be stolen at a gig (other than the PC itself), and both do everything Cubase does without the hassles of hardware dongles which (as previously stated) are last decade.
It used to be there was a perception that server rooms were considered secure. In the past, the access card to the door, after one got past a front desk and the sign in sheet gave enough security show that people trusted colocs with their expensive equipment.
Now that the economy is collapsing, a person at the front desk, an electronic lock on the NOC door, and a key lock on the rack door doesn't cut it anymore. The thugs who used to carjack are now noticing that they can make lots of money, not just on the stolen hardware, but on the contents which can be sold to offshore identity thieves or blackmailers for a hefty profit. Coloc operators now have to factor in armed and forcible intrusions.
As with most security items, this problem sort can be mitigated, but it will take several layers. First, the low-res time lapse cameras have to go that most places use as surveillance. I'd love to see 1024p, but the best around seems to be 480 or 540p for this type of duty. Of course, the footage has to go to a place where the local staff has no access to, preferably to an offsite RAID array.
Second, silent/holdup alarms are needed, and stuff more sophisticated than the panic button under the desk. Preferably on door locks, combine a card reader with a PIN, and a duress code, so an employee can open the door, but yet have help on the way.
Finally, and this is something that is a new field to computing essentially. Servers have to have some defense against console attacks now built into the machine itself. In days past, having servers in the glass room was good enough. Now, because physical access is not a deterrence, servers need to have encryption on their hard disks and arrays, encryption that keeps thieves from accessing data, but (and this is the hard part) doesn't interfere with the server's availability. As of now, there is only one solution out there that allows for encryption of a server's volumes, but still allows a server to boot. Bitlocker + a TPM 1.2 chip.
Bitlocker is the only solution I know of that will let a server boot unattended in a remote location where nobody on site can provide a passphrase to start the machine with normal whole disk encryption, but still will protect the contents on the data volumes against theft or access by booting from another OS. Yes, one can have a smart card that auto-decrypts a key, but one thing BitLocker provides with the TPM hardware is that the code read during boot has not been changed, so someone can't just create a new MBR to compromise the OS.
Yes, the TPM chip has its controversy, but in this context there is no arguing that it is performing a needed function. I'd like to see its functionality combined perhaps with BIOS settings, an intrusion sensor, and perhaps an integral GPS sensor in the machine. Should the machine's BIOS get tampered with, the case opened, or the machine moved by more than a couple hundred feet, the TPM would not give up the key to decrypt the volumes. Of course, the volumes can be unlocked with the manual key or number later on(which is kept in a different location.)
As time goes on, perhaps one item that can be added to servers is a fiber optic security cable with a standard interface. I know universities that use this type of system and should the cable be cut without the right code being inputted, a silent alarm sounds and the university's PD heads over. I think this functionality might be something to add to servers where if the cable is disconnected without explicit setting by a privileged user, the machine would immediately shut down, wipe its RAM, and have the TPM chip not allow access. This would allow servers to be maintained, but if someone tries removing them, the thieves end up with hardware and no data.
Its a sad fact of life, but as time goes on, IBM, Sun, HP, and other high end server makers will have to build in security measures that protect console security, allowing normal administrative tasks, but protecting data against physical removal of equipment, even by authorized people due to armed robberies.
On gigs, its not uncommon for people to try to rip off the USB dongles which are used as license keys for VST plugins and various music software. This sucks because it might cause a band not to be able to complete their set if they don't have backup tracks.
Protecting VST keys for desktop or rackmounts is fairly easy -- you have a USB card with an internal port and plug your VST license dongle into that, leaving that inside the machine. However, for laptops its harder and quite easy for someone to walk up, grab the dongle and run off.