I wonder if the next stage would be "certified" DNS results, where a company gets a certificate signed by their registrar, signs DNS with their own private key, and propagates the results to the secondary servers.
Then clients can grab the results from any DNS server and validate that they are actual results or phonies.
Caveat: This would add another layer of processing and fetching keys, slowing everything down, when DNS is supposed to be a quick way to fetch an IP from a host name. You also have your usual PKI issues as well, such as compromised keys, expired certifications, etc.
Another thing that the hydrogen/fuel cell "economy" is missing is the fact that there are virtually zero hydrogen fueling stops. The cost to put in hundreds of thousands of H2 pumps and the infrastructure to haul the liquid H2 to the corner gas station will be enormous.
Electric cars? Got a 120VAC or a 240VAC outlet? Its not that simple because 120VAC won't charge a car's batteries quickly (though its viable for overnight use.) However, adding circuits and having people standardize on a charging mechanism for cars when parked in parking lots is a lot simpler than the tanks, transportation, and specialized fuel dispensing systems needed for hydrogen. The technology for bringing electricity to every car in a parking lot does exist -- Many Alaskan shops and businesses have plugs for customers to plug in their engine heaters because at -20 (F) and below, the oil starts solidifying in the car.
I look forward to electric cars. In a lot of cities, 100% of power comes from wind and solar, so its not shifting the carbon to another source. Slow charging can be done at home, fast charging (especially with supercap batteries that can charge very quickly) can be done at the normal filling stations, so the existing gas stations won't be losing market anytime soon.
I don't look forward to a hydrogen economy, and the bugs and hassles a vastly new fuel infrastructure will bring with it. Not to mention the fact that someone has to pay the cost of sinking the H2 tanks underground in tens of thousands of gasoline stations... and that will end up being the customer.
This gets me wondering. A printing company like HP could make money hand over fist by designing a printer from the ground up for security. For storing data to be spooled, if the data is in RAM, as soon as the data is printed, the bits of RAM are zeroed out. If the data is stored on a HDD, have the data encrypted with a random key that changes every boot, and perhaps every hour or so if no jobs are in the queue. Of course, this means that any jobs in the printer have to be dropped if there is a power outage. The printer should use reasonable security in its embedded OS and have consideration for buffer overruns and other methods of attack, perhaps having a watchdog circuit that will force a reset if the embedded OS locks up.
Of course, a secure printer should have capture/release functionality where someone can print to the printer, and the job will be held until they are physically at the console and can enter a PIN or perhaps have some type of authentication before the job is printed. This keeps someone from just "accidentally" walking off with a confidential job. Perhaps even have a printer that has secure safety deposit box-like receptacles that open with keys for people who print secure jobs often, but don't want anyone in the office to snatch the output.
Another security device that could be made is a fairly simple embedded firewall between the printer and the rest of the network. This device pretty much would consist of two network interfaces, and some embedded, hardened routing OS. This would be configurable and (for example) would prevent the printer from connecting out (maybe an exception for a machine for SMNP logging), and block any machine that is not in a local subnet from accessing the printer. If this is made inexpensively, this would be a good help in ensuring that only people physically there can access the printer, and the printer cannot send any information out, even if it does get compromised. Maybe HP should put this on their JetDirect interface cards.
On a lower level, I wonder about a modified lpr protocol that would support user authentication before the printer allows anything else to be accessed. The printer can keep a local user access list, or query a LDAP or Active Directory server. In case people forget passwords, have the printer forgot its configuration and return to factory defaults if a hard reset is done (power+OK on HP printers, or perhaps holding down a reset button for 5-10 seconds.) To eliminate brain dead default passwords, the printer should demand the user enter some password in on first power on. At least an attacker would have to guess if a user used "1234" or "ABCDE" for the printer's password.
The trick to this is to encrypt everything. Then, an eavesdropper that sees the cyphertext streams will end up having to store everything, both relevant and irrelevant because he or she doesn't know what is actual valid data, and what is random chaff. By selectively encrypting only the "juicy" stuff, it makes it more of a target.
Of course, the usual analogy: You have a bunch of file cabinets. You could buy one heavy duty, fireproof vault with a X-08 lock on it to store the contents of the one cabinet that has the critical and sensitive business records, and leave the rest of the random manuals and documentation in regular cabinets. Of course, a thief would focus on that safe. Or, you could buy vaults for every file cabinet, and store every piece of paper in those. Then, the attacker would have to drill safe after safe to perhaps find something nontrivial.
This is the case with a number of hardware devices used for cryptography. For example, if a corporate key for signing code is stored on a cryptographic token, and a drunk operator punches the unlock passphrase wrong more than 3-5 times, most likely the device will either lock permanently or zero the key [1]. However, that is the risk you take for the benefit of knowing that if the cryptographic token, be it a CAC, USB pluggable token, or a 3U rack mounted cryptographic coprocessor, is stolen, the key stored inside will not be able to be obtained by a hostile party. This is basic planning, and if someone is seriously worried about the security of a corporate key, perhaps generate it on a PC (which is only used once for this reason, then demilled physically) airgapped from the world, copy the key to multiple cryptographic tokens, then perhaps store a copy of the key shared-split among the corporate officers [2] on USB tokens that each officer secures for the worst case scenario.
For example, if I had a corporate key that was used for code signing or the PKI's root, I would have the corporate officers generate it on an offline PC. The key would then be copied to multiple dedicated cryptographic tokens, with long passphrases, and a retry count of 3-5, where any more wrong guesses than that, and the cryptographic token would permanently deny access. To be safe, I'd use a shared split feature, and split the key among the corporate officers, where a certain quorum of officers would be needed to reconstruct it should all the crypto devices fail. Of course, the PC this token was generated on would have its hard disk not just erased by DBAN, but physically destroyed to the satisfaction of all parties involved so there is no chance of the key being recovered by a dumpster dive.
[1]: You can have some cryptographic tokens have both a user passphrase, and if that gets locked out due to too many retries, an administrative passphrase can unlock and regain access to the keys. Of course, too many guessed passwords on the admin passphrase will lock that for good.
[2]: Shared-splitting is a nice key storage feature in PGP. You can split a key among multiple people, and require X pieces out of Y total to be present for the key to be reconstructed. For example, if a small corporation has four company officers, you can have it where three out of the four officers need to be there to reconstruct a key.
The concept of a copy being genuine applies to the physical media (as opposed to counterfeit CDs). This I understand, and don't mind Microsoft using a load of physical anti-counterfeiting features, from the holograms to the uniquely designed boxes. Making fake physical media and trying to pass it off as copies from Microsoft (as opposed to IP violations) should be a crime with stiff penalties, because this act is obviously theft, where the software vendor has lost money on a bogus copy [1].
For the Windows Genuine Advantage text, if MS does have to have this system in place (which can be argued, I personally detest it, as it only hurts legit, paying users for the most part), I wish MS would just say it like it should be -- "This copy is not properly licensed", as opposed to trying to use a word that is tenuous at best for software. Assuming the software has not been modified, a copy from some really scummy location, and a copy burned to a DVD from the developer's build server are exactly the same. The concept of "genuine" when it comes to ones and zeroes is irrelevant, provided the software has not been tampered with.
[1]: I'm trying to keep separate the two issues of IP violations (copying commercial software), from physical theft (making fake packaging). There are plenty of arguments (pro/con) about IP violations, but I am sure few people would disagree that making counterfeit media and CDs is truly stealing (where the software maker has lost the revenue from a sale, and the counterfeiter has gained money).
WGA should at least give the option to back up its state of that its activated to a certain machine, similar to how one in XP can back up the wpa.bak and wpa.dbl files. Then, in case the machine has to be reinstalled again, Windows can prompt for a copy of these files, and not have to ask for a CD key on future installs.
I come from a UNIX background where the OS is a critical part of not just the computer, but likely the company where its installed, and downtime on a upper end AIX or Solaris production machine or cluster is money lost every second. The OS should have -zero- licensing because its such a critical part of the infrastructure. Applications, licensing is understandable, but the OS itself should just install immediately. This is similar to Tolis BRU's philosophy of allowing access to backed up data regardless of if a license key is entered.
Another possibility, but this is a can of worms, is using a TPM chip to store a certificate. Once the machine is activated to use a certain edition and OS, a certificate is stored in the TPM, similar to how Apple stores a certificate for MacOS. Then, on subsequent installs, the OS just checks to see if its licensed via the TPM for that feature set, and goes on its merry way, never requiring activation again.
Microsoft at least has done a step in the right direction in this case, so I applaud this.
Maybe a cryptographic token is the answer to this, be it an add-on to the SIM card of a cellphone, a civilian CAC, or a custom Aladdin eToken. When a purchase is done, the user has his cryptographic token (preferably by both a fingerprint swipe and a PIN) sign the order.
For validing an ID, all it takes is a government CA adding certs onto someone's public key stating that they are above 21, not a felon, etc. Of course, all the certs are revocable, and ones that would possibly change (absence of a criminal record) would have a fairly short expiration time (as they are easily renewed). For things that are security sensitive (no felonies), the certificate could have a lifespan of days, to ensure that the records are up to date, and provide a failsafe should the certificate recovation server be downed.
Then, if a bar needs proof someone is 21, they swipe the ID card, and then check if the public key shown has a certification from the county or state stating that the person is over 21 years. It doesn't even have to show the exact age of the person, just the fact that they have been documented to be on the planet 21 years.
I'm pretty sure that most MMOs record some conversation passing through their servers, if only to allow people to do a/report of the previous 20 lines of text should someone be spouting obscenities. In other MMOs, there isn't a direct/report command, but the GMs do have access to past chat logs, so when someone puts in a petition or ticket, they can go back and see what the person was writing about.
Most likely, true trained terrorists (not some guys wanting to stick a stink bomb in a high school lunchroom's garbage can) would have a communications channel a lot more secure (doesn't have to be encrypted, just hidden) than gabbing in a MMO, where its unknown to them what parts of a conversation are logged.
I'm wondering about if one could make a very thin metal sheet (almost gold leaf thinness), use the laser technology to etch whatever color is desired, break the sheet up into a powder, then use the powder + a clear solution to hold it in. This should make a workable metallic paint in whatever colors are wanted.
I hope that even with the Hyper-V stuff that is based in Windows Server 2008, that MS keeps VirtualPC updated. For what it does, its excellent as a quick and dirty hypervisor, especially for stuff like Thinstall where you just need to open a VM briefly to do a check before installing, install a program, run the afterwards delta, then build the Thinstalled output. No special client or Web server needed (as opposed to the latest VMWare 2.0 beta which seemed to require a full Java, Apache and Tomcat install and available to the world to even turn on.)
The Hyper-V implementation in the RC1 build of Windows Server 2008 requires your CPU have specific hardware virtualization built in, so you can't really use it on anything less than midrange+ hardware. Maybe its a good thing, as MS is likely intending this for machines designed for being VM servers from the ground up.
What W-USB and Transferjet don't seem to have, but Bluetooth has had for a couple iterations is a decent form of device to device encryption.
If Transferjet was just a protocol that topped out at 3cm, and was totally unreceivable at 1 meter, encryption would be less of an issue. However, even at distances of 3-10 meters, that would be a target of opportunity in some cases. I know that even at the short ranges that Bluetooth works at, I can always find 2-3 people with a Bluetooth enabled phone almost anywhere, and that's with no special equipment, other than a Bluetooth enabled smartphone.
IMHO, encryption needs are a must for any wireless protocol. For example, if people start using W-USB for hard disks, it wouldn't be difficult for someone with a high gain antenna to detect and start injecting packets to read data off (or just format the drive). An attacker can also just passively watch what is shooting across the airwaves to slowly gain a picture of the hard disk's contents.
which erases on the ATA command level. To my knowledge, this will zap data that DBAN misses, because DBAN can't access the hard disk's sector relocation tables (sectors that were about to go bad, so were remapped), and this low level utility is able to.
DBAN plus this utility should be OK for most things, however as always if the drive had relatively sensitive data on it, don't give it away, and destroy it physically (lots of creative methods. For drives I want to be sure that are decommissioned, I personally pull the platters apart, run over them with a vehicle, then chuck each platter in a separate garbage bin.)
Verizon announced that it plans to go GSM in the future, and if they completely phase out CDMA, pretty much only Sprint/Nextel would be the only CDMA provider in the US.
I'm not sure how serious Verizon is about this, although I do know that both AT&T and T-Mobile cross-license their towers, so it doesn't matter what brand of GSM tower is near someone. If Verizon also cross licenses, it wouldn't mean a big expenditure outlay on their part at first (although they would have to build towers to hold up their part of the deal, most likely.)
Maybe this is good -- if the US goes completely GSM, it might allow providers to bring 3G as a standard (instead of EDGE), and perhaps Super3G/4G soon after, but who knows.
Airships have their issues, but I recall reading somewhere that a blimp large enough to carry massive amounts of cargo can do so for the fraction of the fuel spent on ship-based transportation. Ships have to keep expending energy to push through water, but an airship needs far less power to keep a course through the air.
I see a couple hurdles though.
The first is designable around -- damage to the hot air or helium part due to lightning, or tears due to other factors. Having multiple "balloons" might help this situation, so if one is ruptured, the airship still can stay up, or descend in a fairly graceful fashion.
The second is a bit harder, but sort of related to #1. There are people out there (in most areas of the globe) who wouldn't mind taking potshots at an airship. It could be a drunk hillbilly who is playing with his new 30/06, or someone who has a RPG and is hoping to knock the thing out of the air completely. Oddly enough (and I have little or no aerospace expertise), I wonder if, even with major damage from a missile hit, a well engineered airship still can land gracefully (assuming the gondola isn't what is damaged.) Could an airship fly high enough so the chance of getting hit by ground fire be minimized?
Lastly there is a third problem. There is a ton of air traffic already. I wonder how hard it would be to factor in large, slow vehicles into the aviation corridors without impacting takeoffs and landings of jets and prop based traffic.
exFAT was initially designed for Windows CE, for embedded applications which need a filesystem that can handle larger volume and file sizes than FAT or FAT32, but where the embedded device doesn't have the CPU power for the overhead of NTFS. exFAT also supports some optional additions (such as transactions), so if an embedded appliance does have the CPU power, it can support some power failure recovery.
exFAT is not really meant as a primary desktop or server OS filesystem. Its more intended to allow video cameras to make bigger than 4GB movie files on media, allow still cameras to store thousands of photos in a directory (for example, a time-lapse camera which stores a picture every 1-2 seconds), or allow a commodity MP3 player to have a more robust filesystem than FAT.
I just hope Microsoft allows the full specs of this filesystem out, so other operating systems can understand this filesystem. Its a decent successor for FAT32, although for desktop or server duty, NTFS, ext3, xfs, jfs, etc. would be a better choice.
I learned the hard way that the Linksys CD is worthless. Every time I've installed a Linksys router (either for myself or for friends), the CD ends up erroring on the install saying "whups, that's not doable". This occurs even on simple setups where the Linksys router is the firewall, and the wireless access point (its default config). I've found that the only real way to configure the router is to plug a machine into it with a netmask that can address 192.168.1.1, browse the web page at 192.168.1.1, use the usual username "admin", password "password", and manually configure the sucker to what you want.
Call me insane, but I wish for an access point that had a control panel on it so one can punch either an initial IP address/netmask/gateway (or use dhcp), then set a PIN for the inital login. Then, once that is set, you then can browse the router's web page via SSL for the rest of the setup, and change the initial PIN into a more secure passphrase. What security advantage this would offer, is the fact that there would be -no- default password (as if the device is hard reset, before the device gets on the network, it will need a PIN manually set. A user can always use a "default" pin of "1234" or "0000", but that is the user setting lax security, not the device with lame defaults.)
The trick with wireless security is to segment it into independant layers.
First, the router providing the wireless AP access should not be the same router firewalling your LAN from the rest of the Internet. This keeps "management" ports that might accidently be open from being Internet accessible. This is hard sometimes. One router I have has two connections to my little LAN, one from one of its machine ports, and one from its "internet" port. This allows it to check for firmware upgrades and whatnot, letting it think its connected to the Net.
Second, if WEP is all you got [1], put the wireless AP on its own network segment, and have the only way in via a hardened machine with a PPTP/L2TP port and a good username and secure password, secure password being preferably over 30 characters. Then, when (not if) someone does bag the wireless key and hops on the network, they will not obtain much in the way of access. If you can't firewall off your WEP AP, nor are able to replace it, consider making it a daily or weekly item in your schedule to change the WEP key.
I personally avoid the fluff of not broadcasting the SSID, but I do use MAC address protection because its another lock on the front door, and once set up, it really takes little administrative work.
[1]: Only use WEP as a *last resort*. Any router made since 2006 (from what I know) *has* to support WPA-PSK and WPA2-PSK (because WPA and WPA2 are part of the 802.11i spec), so if you can, buy a replacement access point from a CompUSA closeout or something similar and use that. Use a decent (12+ chars) for the router's admin account, and have KeePass generate a 63 character WPA/WPA2 key. I personally generate a 63 char key from KeePass, paste it into the router's config. Then, I copy the key's text into a file on a USB flash disk, carry that to all the machines which use the wireless AP, and paste it in their configs. I have my router set to only allow WPA2 and deny WPA, as all my wireless devices understand AES, but other people may need both WPA and WPA2 available.
Of course, just to be safe, consider changing the WPA/WPA2 key every so often (I've heard monthly to six months.)
When I think of standardized DRM, I am reminded of the Clipper Chip, of the mid 90s. Said chip was being pushed to be a part of pretty much any electronic appliance (computers, cars, modems) for cryptography. To protect the algorithm (which was classified at the time), the chips were highly tamper resistant (for the time), and were programmed with the Skipjack algorithm in a secure location after being made. Of course, we all know how well taken key escrow was at the time, and the Clipper chip died a slow death.
I can see someone coming out with a "TPM v2" chip that, instead of acting like a passive smart card like the 1.2 chip today, it being more of an active function, perhaps doing all the audio and video decoding on it, and only allowing decrypted input to be passed to another, similarly armored and tamper resistant, chip on the monitor. Of course, said "TPM v2" chip would be updatable and images pushed out within hours or days of someone breaching it. It could even be an integral part in the booting/running process of a machine, allowing and denying programs to run. Like the Clipper chip, its manufacture and algorithms can be made classified or top secret.
Then, laws and treaties (similar to WIPO) being put into force that make disassembly or modification of the "offical" chip meaning large amounts of time in a prison, and if one country doesn't enforce the law in their own nation, extradition treaties with another country could force citizens to be tried by judges in other countries.
Of course, somewhere down the line the chip becomes mandatory, similar to the V-Chip is in US TVs, and of course, sooner or later, it will require to phone home to be updated periodically.
Eventually, said chip could be made into something that can scan people's systems for anything that whatever nation thinks is bad, and silently phone home with the info, similar to how Punkbuster and WoW's Warden report people running cheat programs. Then, when someone goes to rip their latest DVD for their iPod, the chip notices the ripping/decoding software, phone homes immediately, and in less than 24 hours, the police arrive with a DMCA-based arrest warrent. (No search warrant would be necessary -- the chip would have done a formal scan of the machine and have sent up in a cryptographically signed/timestamped manner "proof" of the infraction with a list of software present.)
I can see standardized DRM taking place... and its a quite fearful thing, not just combining all the old school cypherpunk's fears with regard to key escrow in hardware, but taking modern issues such as rootkits, spyware, and "super-root" access, and mixing all this into one very noxious hodgepodge.
The same company which currently sell the hand bar code scanner that was mentioned in the article, Microvision, appear to have software just for cataloging books, CDs, DVDs, and anything scannable with a bar code. It didn't state that it could do book organizing in LOC or Dewey Decimal system, but if someone is wanting to do a similar project, to inventory media, it may be something that people could look into.
Hash functions are a relatively young cryptographic technology, only have been around for about fifteen years in the mainstream. Unfortunately, due to this, there are still a lot of bugs to be ironed out. MD5 is (IIRC) only the second generation of hashes. Bulk cryptography has had far longer to evolve, from enigma-type rotor algorithms, to DES, and finally to AES, where each algorithm has been scrutinized for years for any possible issues.
I commend NIST for having a SHA-3 crypto contest. I'm pretty sure something solid will come of it, and if someone *does* know how to generate collisions with the chosen algorithm, they will keep it to themselves very quietly, and not expose it.
One security precaution I do think people should do is go by not just the MD5/SHA hash, but also sign the size of the file. Its a lot harder to generate an evil.exe when it has to be exactly the same size as the good.exe.
Russia having two space ports (similar to how the US has the Kennedy and Johnson space centers) is going to be one of the best things they can do. The more efficient the process of launching stuff into Earth orbit, not to mention out of orbit for interplanetary missions, the closer everyone comes to space based living.
A multinational space race (or even better, cooperative missions) benefits everyone, even if its the side effects of materials developed for aerospace programs being used for everyday life.
This is a gamble on Putin's behalf, but it can pay off big for Russia, because people will be contracting with them for launches of private satellites (new ones, and replacements for existing satellites.)
If I were writing a crypto app for Windows, I'd use my own RNG, and use Windows's as one of the inputs, but not the definitive input. Perhaps have the user wiggle the mouse briefly in a screen to seed a random number pool in RAM, then mix that with other non-periodic sources.
I know TrueCrypt does this, where it uses its own RNG, and uses the OS's (be it Windows or Linux) as input, but not the RNG.
In any case, if an attacker had administrator access, having them guess the output of the RNG is the least of one's worries.
Its highly illegal in the US as well (and almost all countries), so if the website is doing that and is US based, they likely could be facing criminal/civil consequences.
It seems that more and more the Web browser is the focus on attacks these days, so I'm beginning to wonder if not just running Firefox should be the standard, but either running Firefox in a VM (as an ordinary user), or packaging the Web browser with Thinstall (like the Firefox and Opera copies available for download from thinapps.com) so it always runs as a user, and any changes get saved to a sandbox in the user's home directory, and never touch the actual registry.
That is excellent information. It is sort of a guessing game on how long to set a blacklist period. Too short, and you will get hit multiple times by the same perps. Too long, and it hurts someone if the IP block or domain changes hands.
What might be an idea, although this is abusable, would be some way of having a site collect info from others. Say domains A, B, and C are getting hit from the same IP range and blacklist it. They communicate that to some server, so domain D and E would either blacklist or use tarpits/QoS or other precautionary measures until their spam/DoS filters get triggered.
Slashdot Mirror
I wonder if the next stage would be "certified" DNS results, where a company gets a certificate signed by their registrar, signs DNS with their own private key, and propagates the results to the secondary servers.
Then clients can grab the results from any DNS server and validate that they are actual results or phonies.
Caveat: This would add another layer of processing and fetching keys, slowing everything down, when DNS is supposed to be a quick way to fetch an IP from a host name. You also have your usual PKI issues as well, such as compromised keys, expired certifications, etc.
Another thing that the hydrogen/fuel cell "economy" is missing is the fact that there are virtually zero hydrogen fueling stops. The cost to put in hundreds of thousands of H2 pumps and the infrastructure to haul the liquid H2 to the corner gas station will be enormous.
Electric cars? Got a 120VAC or a 240VAC outlet? Its not that simple because 120VAC won't charge a car's batteries quickly (though its viable for overnight use.) However, adding circuits and having people standardize on a charging mechanism for cars when parked in parking lots is a lot simpler than the tanks, transportation, and specialized fuel dispensing systems needed for hydrogen. The technology for bringing electricity to every car in a parking lot does exist -- Many Alaskan shops and businesses have plugs for customers to plug in their engine heaters because at -20 (F) and below, the oil starts solidifying in the car.
I look forward to electric cars. In a lot of cities, 100% of power comes from wind and solar, so its not shifting the carbon to another source. Slow charging can be done at home, fast charging (especially with supercap batteries that can charge very quickly) can be done at the normal filling stations, so the existing gas stations won't be losing market anytime soon.
I don't look forward to a hydrogen economy, and the bugs and hassles a vastly new fuel infrastructure will bring with it. Not to mention the fact that someone has to pay the cost of sinking the H2 tanks underground in tens of thousands of gasoline stations... and that will end up being the customer.
This gets me wondering. A printing company like HP could make money hand over fist by designing a printer from the ground up for security. For storing data to be spooled, if the data is in RAM, as soon as the data is printed, the bits of RAM are zeroed out. If the data is stored on a HDD, have the data encrypted with a random key that changes every boot, and perhaps every hour or so if no jobs are in the queue. Of course, this means that any jobs in the printer have to be dropped if there is a power outage. The printer should use reasonable security in its embedded OS and have consideration for buffer overruns and other methods of attack, perhaps having a watchdog circuit that will force a reset if the embedded OS locks up.
Of course, a secure printer should have capture/release functionality where someone can print to the printer, and the job will be held until they are physically at the console and can enter a PIN or perhaps have some type of authentication before the job is printed. This keeps someone from just "accidentally" walking off with a confidential job. Perhaps even have a printer that has secure safety deposit box-like receptacles that open with keys for people who print secure jobs often, but don't want anyone in the office to snatch the output.
Another security device that could be made is a fairly simple embedded firewall between the printer and the rest of the network. This device pretty much would consist of two network interfaces, and some embedded, hardened routing OS. This would be configurable and (for example) would prevent the printer from connecting out (maybe an exception for a machine for SMNP logging), and block any machine that is not in a local subnet from accessing the printer. If this is made inexpensively, this would be a good help in ensuring that only people physically there can access the printer, and the printer cannot send any information out, even if it does get compromised. Maybe HP should put this on their JetDirect interface cards.
On a lower level, I wonder about a modified lpr protocol that would support user authentication before the printer allows anything else to be accessed. The printer can keep a local user access list, or query a LDAP or Active Directory server. In case people forget passwords, have the printer forgot its configuration and return to factory defaults if a hard reset is done (power+OK on HP printers, or perhaps holding down a reset button for 5-10 seconds.) To eliminate brain dead default passwords, the printer should demand the user enter some password in on first power on. At least an attacker would have to guess if a user used "1234" or "ABCDE" for the printer's password.
The trick to this is to encrypt everything. Then, an eavesdropper that sees the cyphertext streams will end up having to store everything, both relevant and irrelevant because he or she doesn't know what is actual valid data, and what is random chaff. By selectively encrypting only the "juicy" stuff, it makes it more of a target.
Of course, the usual analogy: You have a bunch of file cabinets. You could buy one heavy duty, fireproof vault with a X-08 lock on it to store the contents of the one cabinet that has the critical and sensitive business records, and leave the rest of the random manuals and documentation in regular cabinets. Of course, a thief would focus on that safe. Or, you could buy vaults for every file cabinet, and store every piece of paper in those. Then, the attacker would have to drill safe after safe to perhaps find something nontrivial.
This is the case with a number of hardware devices used for cryptography. For example, if a corporate key for signing code is stored on a cryptographic token, and a drunk operator punches the unlock passphrase wrong more than 3-5 times, most likely the device will either lock permanently or zero the key [1]. However, that is the risk you take for the benefit of knowing that if the cryptographic token, be it a CAC, USB pluggable token, or a 3U rack mounted cryptographic coprocessor, is stolen, the key stored inside will not be able to be obtained by a hostile party. This is basic planning, and if someone is seriously worried about the security of a corporate key, perhaps generate it on a PC (which is only used once for this reason, then demilled physically) airgapped from the world, copy the key to multiple cryptographic tokens, then perhaps store a copy of the key shared-split among the corporate officers [2] on USB tokens that each officer secures for the worst case scenario.
For example, if I had a corporate key that was used for code signing or the PKI's root, I would have the corporate officers generate it on an offline PC. The key would then be copied to multiple dedicated cryptographic tokens, with long passphrases, and a retry count of 3-5, where any more wrong guesses than that, and the cryptographic token would permanently deny access. To be safe, I'd use a shared split feature, and split the key among the corporate officers, where a certain quorum of officers would be needed to reconstruct it should all the crypto devices fail. Of course, the PC this token was generated on would have its hard disk not just erased by DBAN, but physically destroyed to the satisfaction of all parties involved so there is no chance of the key being recovered by a dumpster dive.
[1]: You can have some cryptographic tokens have both a user passphrase, and if that gets locked out due to too many retries, an administrative passphrase can unlock and regain access to the keys. Of course, too many guessed passwords on the admin passphrase will lock that for good.
[2]: Shared-splitting is a nice key storage feature in PGP. You can split a key among multiple people, and require X pieces out of Y total to be present for the key to be reconstructed. For example, if a small corporation has four company officers, you can have it where three out of the four officers need to be there to reconstruct a key.
I agree with you about the genuine concept.
The concept of a copy being genuine applies to the physical media (as opposed to counterfeit CDs). This I understand, and don't mind Microsoft using a load of physical anti-counterfeiting features, from the holograms to the uniquely designed boxes. Making fake physical media and trying to pass it off as copies from Microsoft (as opposed to IP violations) should be a crime with stiff penalties, because this act is obviously theft, where the software vendor has lost money on a bogus copy [1].
For the Windows Genuine Advantage text, if MS does have to have this system in place (which can be argued, I personally detest it, as it only hurts legit, paying users for the most part), I wish MS would just say it like it should be -- "This copy is not properly licensed", as opposed to trying to use a word that is tenuous at best for software. Assuming the software has not been modified, a copy from some really scummy location, and a copy burned to a DVD from the developer's build server are exactly the same. The concept of "genuine" when it comes to ones and zeroes is irrelevant, provided the software has not been tampered with.
[1]: I'm trying to keep separate the two issues of IP violations (copying commercial software), from physical theft (making fake packaging). There are plenty of arguments (pro/con) about IP violations, but I am sure few people would disagree that making counterfeit media and CDs is truly stealing (where the software maker has lost the revenue from a sale, and the counterfeiter has gained money).
WGA should at least give the option to back up its state of that its activated to a certain machine, similar to how one in XP can back up the wpa.bak and wpa.dbl files. Then, in case the machine has to be reinstalled again, Windows can prompt for a copy of these files, and not have to ask for a CD key on future installs.
I come from a UNIX background where the OS is a critical part of not just the computer, but likely the company where its installed, and downtime on a upper end AIX or Solaris production machine or cluster is money lost every second. The OS should have -zero- licensing because its such a critical part of the infrastructure. Applications, licensing is understandable, but the OS itself should just install immediately. This is similar to Tolis BRU's philosophy of allowing access to backed up data regardless of if a license key is entered.
Another possibility, but this is a can of worms, is using a TPM chip to store a certificate. Once the machine is activated to use a certain edition and OS, a certificate is stored in the TPM, similar to how Apple stores a certificate for MacOS. Then, on subsequent installs, the OS just checks to see if its licensed via the TPM for that feature set, and goes on its merry way, never requiring activation again.
Microsoft at least has done a step in the right direction in this case, so I applaud this.
Maybe a cryptographic token is the answer to this, be it an add-on to the SIM card of a cellphone, a civilian CAC, or a custom Aladdin eToken. When a purchase is done, the user has his cryptographic token (preferably by both a fingerprint swipe and a PIN) sign the order.
For validing an ID, all it takes is a government CA adding certs onto someone's public key stating that they are above 21, not a felon, etc. Of course, all the certs are revocable, and ones that would possibly change (absence of a criminal record) would have a fairly short expiration time (as they are easily renewed). For things that are security sensitive (no felonies), the certificate could have a lifespan of days, to ensure that the records are up to date, and provide a failsafe should the certificate recovation server be downed.
Then, if a bar needs proof someone is 21, they swipe the ID card, and then check if the public key shown has a certification from the county or state stating that the person is over 21 years. It doesn't even have to show the exact age of the person, just the fact that they have been documented to be on the planet 21 years.
I'm pretty sure that most MMOs record some conversation passing through their servers, if only to allow people to do a /report of the previous 20 lines of text should someone be spouting obscenities. In other MMOs, there isn't a direct /report command, but the GMs do have access to past chat logs, so when someone puts in a petition or ticket, they can go back and see what the person was writing about.
Most likely, true trained terrorists (not some guys wanting to stick a stink bomb in a high school lunchroom's garbage can) would have a communications channel a lot more secure (doesn't have to be encrypted, just hidden) than gabbing in a MMO, where its unknown to them what parts of a conversation are logged.
I'm wondering about if one could make a very thin metal sheet (almost gold leaf thinness), use the laser technology to etch whatever color is desired, break the sheet up into a powder, then use the powder + a clear solution to hold it in. This should make a workable metallic paint in whatever colors are wanted.
I hope that even with the Hyper-V stuff that is based in Windows Server 2008, that MS keeps VirtualPC updated. For what it does, its excellent as a quick and dirty hypervisor, especially for stuff like Thinstall where you just need to open a VM briefly to do a check before installing, install a program, run the afterwards delta, then build the Thinstalled output. No special client or Web server needed (as opposed to the latest VMWare 2.0 beta which seemed to require a full Java, Apache and Tomcat install and available to the world to even turn on.)
The Hyper-V implementation in the RC1 build of Windows Server 2008 requires your CPU have specific hardware virtualization built in, so you can't really use it on anything less than midrange+ hardware. Maybe its a good thing, as MS is likely intending this for machines designed for being VM servers from the ground up.
What W-USB and Transferjet don't seem to have, but Bluetooth has had for a couple iterations is a decent form of device to device encryption.
If Transferjet was just a protocol that topped out at 3cm, and was totally unreceivable at 1 meter, encryption would be less of an issue. However, even at distances of 3-10 meters, that would be a target of opportunity in some cases. I know that even at the short ranges that Bluetooth works at, I can always find 2-3 people with a Bluetooth enabled phone almost anywhere, and that's with no special equipment, other than a Bluetooth enabled smartphone.
IMHO, encryption needs are a must for any wireless protocol. For example, if people start using W-USB for hard disks, it wouldn't be difficult for someone with a high gain antenna to detect and start injecting packets to read data off (or just format the drive). An attacker can also just passively watch what is shooting across the airwaves to slowly gain a picture of the hard disk's contents.
There is a low level drive utility,
http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml
which erases on the ATA command level. To my knowledge, this will zap data that DBAN misses, because DBAN can't access the hard disk's sector relocation tables (sectors that were about to go bad, so were remapped), and this low level utility is able to.
DBAN plus this utility should be OK for most things, however as always if the drive had relatively sensitive data on it, don't give it away, and destroy it physically (lots of creative methods. For drives I want to be sure that are decommissioned, I personally pull the platters apart, run over them with a vehicle, then chuck each platter in a separate garbage bin.)
Verizon announced that it plans to go GSM in the future, and if they completely phase out CDMA, pretty much only Sprint/Nextel would be the only CDMA provider in the US.
I'm not sure how serious Verizon is about this, although I do know that both AT&T and T-Mobile cross-license their towers, so it doesn't matter what brand of GSM tower is near someone. If Verizon also cross licenses, it wouldn't mean a big expenditure outlay on their part at first (although they would have to build towers to hold up their part of the deal, most likely.)
Maybe this is good -- if the US goes completely GSM, it might allow providers to bring 3G as a standard (instead of EDGE), and perhaps Super3G/4G soon after, but who knows.
Airships have their issues, but I recall reading somewhere that a blimp large enough to carry massive amounts of cargo can do so for the fraction of the fuel spent on ship-based transportation. Ships have to keep expending energy to push through water, but an airship needs far less power to keep a course through the air.
I see a couple hurdles though.
The first is designable around -- damage to the hot air or helium part due to lightning, or tears due to other factors. Having multiple "balloons" might help this situation, so if one is ruptured, the airship still can stay up, or descend in a fairly graceful fashion.
The second is a bit harder, but sort of related to #1. There are people out there (in most areas of the globe) who wouldn't mind taking potshots at an airship. It could be a drunk hillbilly who is playing with his new 30/06, or someone who has a RPG and is hoping to knock the thing out of the air completely. Oddly enough (and I have little or no aerospace expertise), I wonder if, even with major damage from a missile hit, a well engineered airship still can land gracefully (assuming the gondola isn't what is damaged.) Could an airship fly high enough so the chance of getting hit by ground fire be minimized?
Lastly there is a third problem. There is a ton of air traffic already. I wonder how hard it would be to factor in large, slow vehicles into the aviation corridors without impacting takeoffs and landings of jets and prop based traffic.
exFAT was initially designed for Windows CE, for embedded applications which need a filesystem that can handle larger volume and file sizes than FAT or FAT32, but where the embedded device doesn't have the CPU power for the overhead of NTFS. exFAT also supports some optional additions (such as transactions), so if an embedded appliance does have the CPU power, it can support some power failure recovery.
exFAT is not really meant as a primary desktop or server OS filesystem. Its more intended to allow video cameras to make bigger than 4GB movie files on media, allow still cameras to store thousands of photos in a directory (for example, a time-lapse camera which stores a picture every 1-2 seconds), or allow a commodity MP3 player to have a more robust filesystem than FAT.
I just hope Microsoft allows the full specs of this filesystem out, so other operating systems can understand this filesystem. Its a decent successor for FAT32, although for desktop or server duty, NTFS, ext3, xfs, jfs, etc. would be a better choice.
I learned the hard way that the Linksys CD is worthless. Every time I've installed a Linksys router (either for myself or for friends), the CD ends up erroring on the install saying "whups, that's not doable". This occurs even on simple setups where the Linksys router is the firewall, and the wireless access point (its default config). I've found that the only real way to configure the router is to plug a machine into it with a netmask that can address 192.168.1.1, browse the web page at 192.168.1.1, use the usual username "admin", password "password", and manually configure the sucker to what you want.
Call me insane, but I wish for an access point that had a control panel on it so one can punch either an initial IP address/netmask/gateway (or use dhcp), then set a PIN for the inital login. Then, once that is set, you then can browse the router's web page via SSL for the rest of the setup, and change the initial PIN into a more secure passphrase. What security advantage this would offer, is the fact that there would be -no- default password (as if the device is hard reset, before the device gets on the network, it will need a PIN manually set. A user can always use a "default" pin of "1234" or "0000", but that is the user setting lax security, not the device with lame defaults.)
The trick with wireless security is to segment it into independant layers.
First, the router providing the wireless AP access should not be the same router firewalling your LAN from the rest of the Internet. This keeps "management" ports that might accidently be open from being Internet accessible. This is hard sometimes. One router I have has two connections to my little LAN, one from one of its machine ports, and one from its "internet" port. This allows it to check for firmware upgrades and whatnot, letting it think its connected to the Net.
Second, if WEP is all you got [1], put the wireless AP on its own network segment, and have the only way in via a hardened machine with a PPTP/L2TP port and a good username and secure password, secure password being preferably over 30 characters. Then, when (not if) someone does bag the wireless key and hops on the network, they will not obtain much in the way of access. If you can't firewall off your WEP AP, nor are able to replace it, consider making it a daily or weekly item in your schedule to change the WEP key.
I personally avoid the fluff of not broadcasting the SSID, but I do use MAC address protection because its another lock on the front door, and once set up, it really takes little administrative work.
[1]: Only use WEP as a *last resort*. Any router made since 2006 (from what I know) *has* to support WPA-PSK and WPA2-PSK (because WPA and WPA2 are part of the 802.11i spec), so if you can, buy a replacement access point from a CompUSA closeout or something similar and use that. Use a decent (12+ chars) for the router's admin account, and have KeePass generate a 63 character WPA/WPA2 key. I personally generate a 63 char key from KeePass, paste it into the router's config. Then, I copy the key's text into a file on a USB flash disk, carry that to all the machines which use the wireless AP, and paste it in their configs. I have my router set to only allow WPA2 and deny WPA, as all my wireless devices understand AES, but other people may need both WPA and WPA2 available.
Of course, just to be safe, consider changing the WPA/WPA2 key every so often (I've heard monthly to six months.)
When I think of standardized DRM, I am reminded of the Clipper Chip, of the mid 90s. Said chip was being pushed to be a part of pretty much any electronic appliance (computers, cars, modems) for cryptography. To protect the algorithm (which was classified at the time), the chips were highly tamper resistant (for the time), and were programmed with the Skipjack algorithm in a secure location after being made. Of course, we all know how well taken key escrow was at the time, and the Clipper chip died a slow death.
I can see someone coming out with a "TPM v2" chip that, instead of acting like a passive smart card like the 1.2 chip today, it being more of an active function, perhaps doing all the audio and video decoding on it, and only allowing decrypted input to be passed to another, similarly armored and tamper resistant, chip on the monitor. Of course, said "TPM v2" chip would be updatable and images pushed out within hours or days of someone breaching it. It could even be an integral part in the booting/running process of a machine, allowing and denying programs to run. Like the Clipper chip, its manufacture and algorithms can be made classified or top secret.
Then, laws and treaties (similar to WIPO) being put into force that make disassembly or modification of the "offical" chip meaning large amounts of time in a prison, and if one country doesn't enforce the law in their own nation, extradition treaties with another country could force citizens to be tried by judges in other countries.
Of course, somewhere down the line the chip becomes mandatory, similar to the V-Chip is in US TVs, and of course, sooner or later, it will require to phone home to be updated periodically.
Eventually, said chip could be made into something that can scan people's systems for anything that whatever nation thinks is bad, and silently phone home with the info, similar to how Punkbuster and WoW's Warden report people running cheat programs. Then, when someone goes to rip their latest DVD for their iPod, the chip notices the ripping/decoding software, phone homes immediately, and in less than 24 hours, the police arrive with a DMCA-based arrest warrent. (No search warrant would be necessary -- the chip would have done a formal scan of the machine and have sent up in a cryptographically signed/timestamped manner "proof" of the infraction with a list of software present.)
I can see standardized DRM taking place... and its a quite fearful thing, not just combining all the old school cypherpunk's fears with regard to key escrow in hardware, but taking modern issues such as rootkits, spyware, and "super-root" access, and mixing all this into one very noxious hodgepodge.
The same company which currently sell the hand bar code scanner that was mentioned in the article, Microvision, appear to have software just for cataloging books, CDs, DVDs, and anything scannable with a bar code. It didn't state that it could do book organizing in LOC or Dewey Decimal system, but if someone is wanting to do a similar project, to inventory media, it may be something that people could look into.
Hash functions are a relatively young cryptographic technology, only have been around for about fifteen years in the mainstream. Unfortunately, due to this, there are still a lot of bugs to be ironed out. MD5 is (IIRC) only the second generation of hashes. Bulk cryptography has had far longer to evolve, from enigma-type rotor algorithms, to DES, and finally to AES, where each algorithm has been scrutinized for years for any possible issues.
I commend NIST for having a SHA-3 crypto contest. I'm pretty sure something solid will come of it, and if someone *does* know how to generate collisions with the chosen algorithm, they will keep it to themselves very quietly, and not expose it.
One security precaution I do think people should do is go by not just the MD5/SHA hash, but also sign the size of the file. Its a lot harder to generate an evil.exe when it has to be exactly the same size as the good.exe.
Russia having two space ports (similar to how the US has the Kennedy and Johnson space centers) is going to be one of the best things they can do. The more efficient the process of launching stuff into Earth orbit, not to mention out of orbit for interplanetary missions, the closer everyone comes to space based living.
A multinational space race (or even better, cooperative missions) benefits everyone, even if its the side effects of materials developed for aerospace programs being used for everyday life.
This is a gamble on Putin's behalf, but it can pay off big for Russia, because people will be contracting with them for launches of private satellites (new ones, and replacements for existing satellites.)
If I were writing a crypto app for Windows, I'd use my own RNG, and use Windows's as one of the inputs, but not the definitive input. Perhaps have the user wiggle the mouse briefly in a screen to seed a random number pool in RAM, then mix that with other non-periodic sources.
I know TrueCrypt does this, where it uses its own RNG, and uses the OS's (be it Windows or Linux) as input, but not the RNG.
In any case, if an attacker had administrator access, having them guess the output of the RNG is the least of one's worries.
Its highly illegal in the US as well (and almost all countries), so if the website is doing that and is US based, they likely could be facing criminal/civil consequences.
It seems that more and more the Web browser is the focus on attacks these days, so I'm beginning to wonder if not just running Firefox should be the standard, but either running Firefox in a VM (as an ordinary user), or packaging the Web browser with Thinstall (like the Firefox and Opera copies available for download from thinapps.com) so it always runs as a user, and any changes get saved to a sandbox in the user's home directory, and never touch the actual registry.
That is excellent information. It is sort of a guessing game on how long to set a blacklist period. Too short, and you will get hit multiple times by the same perps. Too long, and it hurts someone if the IP block or domain changes hands.
What might be an idea, although this is abusable, would be some way of having a site collect info from others. Say domains A, B, and C are getting hit from the same IP range and blacklist it. They communicate that to some server, so domain D and E would either blacklist or use tarpits/QoS or other precautionary measures until their spam/DoS filters get triggered.