I had to deal with a similar setup a few years ago. What I did was put them on their own Ethernet segment that was completely isolated from everything but one machine. Even the subnet had a separate hardware switch so there was no way (other than physical access or compromise of the telnet server) that the unencrypted traffic could be intercepted. This machine was what people telnetted into, then ssh-ed out from to do work. This way, the only real weak link were the paths from the terminals to the switch, and the switch to the telnet server.
Of course, this may not be possible in all environments, but putting a box that is just used for telnetting into and either directly connecting terminals to that box via crossover cables, or using a good switch may help mitigate things.
For now that is. If people start getting arrested left and right for stuff they did on their ISP, or their school suspends/expels them for activities done at home, people will start caring and start locking their business down.
I think it is only a matter of time before we start seeing some extremely large anonymous VPN services appearing, and an anonymous service provider will be as needed as an ISP.
Those logs will be REALLY useful to a bunch of people, and not just LEOs.
Take lawsuits on a large scale. It would be trivial to get a litigation group together to demand ISP logs, riffle through them and build massive copyright lawsuits on the ISP's customers based on sites visited, and perhaps info downloaded. Remember: if it swings past a jury, it works, so it doesn't have to be CSI level of evidence for proof, just something to show it is more likely Joe Sixpack downloaded a movie than not likely. So, someone could make a litigation corporation whose sole job is just going through ISP logs and suing people, then maybe handing a penny or two on the dollar to the legitimate copyright holder.
Of course, the criminal element would LOVE logs like this. With how some ISPs store data, security is really not on the list, because there is no ROI in keeping information locked down. However, if a blackhat got stored ISP data on a large number of individuals, it could be easily sold and used for a lot of really nasty stuff:
1: Blackmail. Someone who works at a conservative establishment would pay big dollars of hush money to a group who would otherwise make public the fact that he often visits certain pr0n sites, his username, what subscriptions he has, and what he posts.
2: Extortion. Blackhats could use ISP logs to find a business's customers, accounts payable, accounts receivable, suppliers, and other parties, then ask for a "protection fee", or else the business's partners would be attacked.
Knowledge is power. By forcing ISPs to keep this information, it becomes a gold mine to a lot of unsavory types.
As for LEOs wanting this, this just seems like a case in frying pan into fire. Once Jack Scumbag realizes that ISPs are handing all the traffic to LEOs and the LEOs are arresting people left and right, he is just going to fire up an anonymous VPN that is offshore and use that.
Given parties with enough cash/clout, any treaty can be set aside. I'd bet that if a party well-heeled enough to get a mining system set up to get rare minerals from the moon to Earth on a fairly inexpensive basis (perhaps with a space elevator), the Outer Space Treaty would be shelved or amended to nothingness by at least one country.
Good luck finding an insurance company that does cover loss or theft dongles for more than their replacement value (and that is the value of the hardware, not the hardware + the keys that make the software work.) This is something I have seen a good number of musicians look for, and not find. Convincing an insurance adjuster to cut a check for the thousands it costs to replace Cubase + the plugin licenses will be almost impossible, even with proper receipts at hand. I have yet to find a single musician who has been successful at finding an insurance company that will insure those things. Other gear, sure. Insurance will cover a lost Macbook or a stolen keyboard while a band is on the road.
So far, the only "insurance" that works in this case is what I did for a couple musicians with the locking 1U rack. Other musicians just use crack the software so their whole gig doesn't depend if some DRM chooses to run or not.
A dongle != a musical instrument. Insurance companies may only cover the physical value of the dongle and not the license keys involved, and have a good chance of sending a settlement check good enough for a six pack of PBR and no more. You have to make sure your insurance company explicitly knows what those are, and covers the stored value of the VST plugins and other items that are on the dongle.
A car example: If someone steals a key to a vehicle, the insurance company might reimburse for the lost piece of metal, but likely not cover the reprogramming of the PATS system to allow that key to work in the ignition.
Don't forget inconvenience. Losing a dongle can be worse than losing a computer. With a lost laptop, assuming decent backups using Time Machine or even Mozy/Carbonite/Backblaze, the data and apps can be restored and work can continue. No music software means the gig is dead in the water without alternate plans.
From what I have seen with Steinberg's stuff, I have not encountered any musicians who really like it. First, there is the dongle/VST plugin aspect. Start setting up at a gig, and some crackhead makes off with your dongle? From what I know, a musician either has to hit the warez/crack sites, or re-buy everything. To prevent this from happening, I have had made at a metal shop custom 1U locking rack drawers that had a powered USB hub mounted in the back, just so people could have their license key stuff secured at a concert.
I wonder why Steinberg continues to do dongles, especially with pro-quality tools like ACID Pro on the Windows side, and Logic Studio on the Mac side being so relatively inexpensive. The only way I see Steinberg's offerings being relevant these days is if someone needed a certain VST plugin that didn't work on other VST hosts.
I'd add four things to using a VM for untrusted stuff:
1: Roll back the VM, back it up if you so choose, then run Windows/Microsoft update and update the other programs at least monthly. Then back up the.vmdk files again.
2: Buy a copy of sandboxie for the VM. This way, the malicious software would have to get through that before being able to use kernel level abilities in case there is a 0-day to allow malware to get out past the hypervisor.
3: Run the potentially nasty stuff as a user with no admin rights. Bonus points for running DropMyRights for even less privileges given to the process.
4: Use a proxy (or at least yank the VM's access to the network), so if stuff phones home, it doesn't have your real IP address.
Untrusted stuff isn't just keygens. I tend to run tools which I download for one purpose in a VM just so I know they do the job at hand with a file, and no more. For example, if I'm using a utility I downloaded to strip off the EXIF data from a number of pictures for privacy reasons, I stick the pictures in the VM, run the utility, power off the VM, mount the disk image, yank off the processed photos, unmount the image, and then roll it back. This way, if the utility were malicious, the only persistent data it could affect would be the picture files.
Exactly. For example, any machines I have which have to have an Internet facing ssh port are definitely not going to be accepting passwords. Tools like ssh-guard are nice, but it isn't hard for a determined attacker to just keep coming from different IP ranges. To add a little bit of security, port knocking is a nice ability to have, just so an attacker doesn't see an open port to start having fun with.
What would be ideal is if OATH support would advance to the point where I can just enter my username, then my password and then the random key from a SecurID or other token. This way, an attacker would have to go from passively looking at passwords as they float by to actively MITM-ing the connection.
Tata is making subcompacts in India which use this exact method as a propulsion source to get around. However, what works over there might not work over here.
But, if the technology makes it over, just the fact that it can keep a vehicle running with the gasoline or diesel engine off at idle to low speeds in city traffic would save a good amount of fuel.
There are a lot of places other than FB which don't encrypt their traffic other than the initial username/password. Mainly because it is cheap to do so (plain http connections after authentication can be cached, no need to set up and tear down encrypted sockets, etc.)
However what was par for security even last year before widespread sidejacking tools like FireSheep became available is now considered a wide open security risk. Just like how companies have to firewall their networks with the expense involved in having network security, separating departments, and such, companies will have to move to SSL for the entire transaction with their visitors or customers.
+1. I know FB would rake in the bucks if they offered a premium service that had https by default, no ads, and the ability to use a VASCO or SecurID keyfob (with OATH certification when logging from PCs, and for non-PCs, the FB app has the ability to set a PIN.)
I'd pay the usual $20 a year for this easily, mainly because FB is a good tool for keeping track of band and other events going on locally.
True, a power station would be more straightforward. However, fewer people would consider that a fuel refinery would actually be running a cheap energy source in the basement than a power station. The trick is to use a pipeline as opposed to actual freight shipping, so nobody is the wiser that the pipeline has not has anything run through it. Easier on the books that way.
There are plenty of other places where people wouldn't be looking for a man behind the curtain: Even a data center which sits in the middle of nowhere with several 120VAC connections to the grid (need that redundancy) might be plausible, assuming someone who isn't versed in electricity doesn't show up and wonder how a few 480VAC transformers (that have not been touched since a mobile home park necessitated their installation in the 1970s) are handling the complete load of a facility using 20-30 megawatts.
If one really wanted to keep the technology secret, but still make a profit from it, one could just create an oil "refinery" that makes and sells gasoline. Yes, it might have incoming pipes from an upstream source, but those pipes never have been turned on. The oil is paid for but the upstream seller has never bothered to deliver on it. In reality, the gasoline being sold from the "refinery" would be CO2 pulled out of the air, dumped through a ton of energy expensive chemical processes, and then dumped in the semis ready to haul to the local 7-11 pump. It doesn't matter how expensive energy-wise the reactions would be.
Result: A decent profit, nobody ever the wiser (except the oil seller upstream who has to keep it secret why they sell oil to someone, but in reality they have not even opened the pipeline to deliver a gallon), and definitely nobody would suspect a cheap energy source. Combine it with the energy source powering up the reactor, and one has a carbon-negative business.
There is also the fact that one has to get a CHL (concealed handgun license) in either revolver or semi-auto, and have to carry the right firearm for the license.
I'd agree that Texas used to be on the bottom of the list, but has moved up. However, don't let the talk about "castle doctrine" and other laws fool people. There are a good number of people who are going to spend a good chunk of their lives (if not the rest of it) in TDCJ prisons because they did not understand the law and have taken potshots at either someone breaking into a neighbor's property, someone who cut them off on the highway, or someone that looked suspicious.
If auto makers could use those "smart screws" that flip between open and shut, they could. Mainly because it would allow ease of making stuff without worry about tool paths.
However, these devices have one flaw -- a battery powerful and reliable enough to allow the fastener to pop open after 10-20 years in the field when it comes time to service something.
Perhaps, we will see cases held together by solenoids that only retract after the right code is entered to the software. However, there are always bugs. For example, some old Compaq workstations had a solenoid case lock as an option. Of course, if the battery in the case went out, or the keyboard controller died, it would take the manual method; Compaq bundled a screwdriver that you used to take the three screws holding in the solenoid lock, and you would open the case as normal.
What a fair compromise would be is Motorola having a model of phone just for the modder crowd. Hell, charge full price and have it unlocked. Sell it as the hacker's dream toy, similar to a N900 where (assuming it came with decent specs), people can go ape with it, and have it do new and cool things.
It doesn't just have to be aimed at the percent of the buyers who just mod. Aim it at people who are tech savvy and/or creative. If someone buys it and keeps it stock, unrooted, with full MotoBLUR, that's great. If someone else fastboot oem-unlocks it to stick a full Debian distro on it, rock on.
That is the rub. I've learned that the ONLY handsets which will guarantee ROM updating will be Google's reference models, the ADP1, ADP2, Nexus 1, and Nexus S.
What I'm hoping for is that Google can get a reference model made for Honeycomb that has a decent sliding keyboard and a MicroSD card slot. 24 GB just doesn't cut it, and even then, it is nice to be able to stick a card in, nandroid backup your ROM and titanium backup all your apps before hitting the road for a long trip with the SD card that holds all your MP3s.
I just hope the Nexus S's successor has at least has SDXC card capability. If not, guess it will be time to wait for the reference model when Ice Cream goes GA.
I'd love to see that technology become common in the US for a completely different reason, and that is to separate work data and home data. Combine this with virtualization, and this would be great for people who use their devices for work and home stuff. Leave a job and the IT staff sends a self-destruct signal? It only gets rid of the work based VM.
Done right, it can be made decently secure as well.
Of course, having the ability to switch SIMs for one machine is cool too, not just for cheap call rates. Say provider "A" is 4G but has a pathetic limit, provider "B" has 4G, but charges fees after a gig or two, and provider "C" is 3G, but is unlimited. The phone can use provider "A" until the bandwidth is exhausted, switch to provider "B", then to "C", until the month resets and "A" is useful again. Add QoS so important traffic (E-mail) goes over one link and other stuff goes over another, and this would be a very good thing (tm) to have.
Even more ironic -- the providers in Asia use R/UIM cards, which are functionally identical in size and shape to SIM cards, but are for CDMA networks. Combine this with a radio that handles CDMA and GSM, and even the US's big divide between providers can be bridged to allow one device to work anywhere. Hopefully everyone adapting LTE will make the need for SIM versus R/UIM cards not needed, but who knows. I'm afraid the CDMA providers won't use SIM technology when LTE comes online, so even if a device is LTE based, a provider can just say no when a customer calls and begs for it to be activated.
I'd like to see more phones have the option to completely erase contents after "X" period of time with no network signal. This way, someone can't just pull a SIM card to keep access.
As for remote wipes, sometimes phones do provide non-corporate customers the way to do this. Apple does, (you used to need a.me.com account, but apparently with iOS 4.2.1, not anymore.) Motorola's Motoblur accounts also have this ability as well.
I do think having E-mail with an Exchange provider (that supports OWA) is a good thing even with these options, just because of the ability to wipe the contents using a different mechanism.
If I stuck a deadbolt cylinder on a hollow core door used for internal rooms, someone could easily kick it in without a moment's thought.
If I stuck a cylinder on a European lock that had multipoint locking, a solid jamb that uses steel rails that are sunk into the foundation, it would require a hydraulic ram to open it.
Similar with phones. If I stuck a PIN on an open device, there would be ways to get around it. However, if the device was built from the ground up with encrypted filesystems, keys in a secure RAM partition, and anti-brute force code where PIN guessing resulted in longer delays, and eventually a complete zeroization of the device, the same PIN that might be worthless on one device may adequately protect another.
One can see this when comparing a TrueCrypt keyfile stored on a cryptographic token (or an IronKey) compared to one stored on a generic USB flash drive. After try #20 with the USB flash drive, it doesn't matter, especially if one just copies the cyphertext to another image to protect against self destruct software. The same data stored on a hardware device using hardware encryption will be long gone before attempt #20 could even be made.
A 4 digit PIN can be excellent protection, or it can be a joke depending on how the device is architected.
Very true. If SHA-X was secure for the foreseeable future, there wouldn't be a contest going on for someone to make a replacement algorithm for the SHA-3 name. In the meantime, it would be nice for Whirlpool, Skein, or another well tested hash function to take up the slack.
However, the hash functions are open for all to look at. This beats someone stuffing all the data into an 8 bit LFSR, yanking 128 bits out and calling that a cryptographically secure hash.
Exactly. The usual solution is to have something like a McAfee command line scanner [1]. Then cron it up every so often to do a file scan when absolutely nothing is going on. In reality, this is only useful for samba servers, but because for CYA reasons, I have it scan everything else every so often.
Hrm... when it comes to numbers of compromised devices, both the iPhone and Android have not had any real intrusions (other than some jailbroken devices with the root password still set to "alpine" and sshd enabled.)
The security mechanisms of both operating systems are both pretty open. Android uses the Dalvik VM to sandbox, and Linux's user level protection to keep apps in their directories. iOS uses chroot() and the mobile user to enforce its security. Which is better? This can be argued endlessly. Both are quite good.
So why is this guy saying Android is insecure? If he knows something that is a fundamental flaw in Android's design, he should state it, otherwise, he is espousing FUD.
In the 1990s, there were a lot of people who made their own encryption algorithms, of course they were "secret" for their own encryption products. Not surprisingly, a lot of them were just using rand() with the password the user types in as the seed for srand() and then XOR-ing the data. To the casual user, random cyphertext is random cyphertext. However, it doesn't take long to spin through 65536 possibilities for a seed.
Of course, we had Clipper/Skipjack. I'd dread what life would be like if we had to trust the encryption on that chip (without knowing anything about the algorithm), and nevermind who had access to the LEAF fields. Probably most of the/. readers would have found a way to zero out the LEAF fields so the key couldn't be pulled out of escrow.
I'm just glad we have decent, open cryptographic standards. If a product doesn't use AES with a good implementation other than ECB, find something that does. RSA and SHA1 are not perfect, but so far, they have been secure.
Slashdot Mirror
I had to deal with a similar setup a few years ago. What I did was put them on their own Ethernet segment that was completely isolated from everything but one machine. Even the subnet had a separate hardware switch so there was no way (other than physical access or compromise of the telnet server) that the unencrypted traffic could be intercepted. This machine was what people telnetted into, then ssh-ed out from to do work. This way, the only real weak link were the paths from the terminals to the switch, and the switch to the telnet server.
Of course, this may not be possible in all environments, but putting a box that is just used for telnetting into and either directly connecting terminals to that box via crossover cables, or using a good switch may help mitigate things.
For now that is. If people start getting arrested left and right for stuff they did on their ISP, or their school suspends/expels them for activities done at home, people will start caring and start locking their business down.
I think it is only a matter of time before we start seeing some extremely large anonymous VPN services appearing, and an anonymous service provider will be as needed as an ISP.
Those logs will be REALLY useful to a bunch of people, and not just LEOs.
Take lawsuits on a large scale. It would be trivial to get a litigation group together to demand ISP logs, riffle through them and build massive copyright lawsuits on the ISP's customers based on sites visited, and perhaps info downloaded. Remember: if it swings past a jury, it works, so it doesn't have to be CSI level of evidence for proof, just something to show it is more likely Joe Sixpack downloaded a movie than not likely. So, someone could make a litigation corporation whose sole job is just going through ISP logs and suing people, then maybe handing a penny or two on the dollar to the legitimate copyright holder.
Of course, the criminal element would LOVE logs like this. With how some ISPs store data, security is really not on the list, because there is no ROI in keeping information locked down. However, if a blackhat got stored ISP data on a large number of individuals, it could be easily sold and used for a lot of really nasty stuff:
1: Blackmail. Someone who works at a conservative establishment would pay big dollars of hush money to a group who would otherwise make public the fact that he often visits certain pr0n sites, his username, what subscriptions he has, and what he posts.
2: Extortion. Blackhats could use ISP logs to find a business's customers, accounts payable, accounts receivable, suppliers, and other parties, then ask for a "protection fee", or else the business's partners would be attacked.
Knowledge is power. By forcing ISPs to keep this information, it becomes a gold mine to a lot of unsavory types.
As for LEOs wanting this, this just seems like a case in frying pan into fire. Once Jack Scumbag realizes that ISPs are handing all the traffic to LEOs and the LEOs are arresting people left and right, he is just going to fire up an anonymous VPN that is offshore and use that.
Given parties with enough cash/clout, any treaty can be set aside. I'd bet that if a party well-heeled enough to get a mining system set up to get rare minerals from the moon to Earth on a fairly inexpensive basis (perhaps with a space elevator), the Outer Space Treaty would be shelved or amended to nothingness by at least one country.
Good luck finding an insurance company that does cover loss or theft dongles for more than their replacement value (and that is the value of the hardware, not the hardware + the keys that make the software work.) This is something I have seen a good number of musicians look for, and not find. Convincing an insurance adjuster to cut a check for the thousands it costs to replace Cubase + the plugin licenses will be almost impossible, even with proper receipts at hand. I have yet to find a single musician who has been successful at finding an insurance company that will insure those things. Other gear, sure. Insurance will cover a lost Macbook or a stolen keyboard while a band is on the road.
So far, the only "insurance" that works in this case is what I did for a couple musicians with the locking 1U rack. Other musicians just use crack the software so their whole gig doesn't depend if some DRM chooses to run or not.
A dongle != a musical instrument. Insurance companies may only cover the physical value of the dongle and not the license keys involved, and have a good chance of sending a settlement check good enough for a six pack of PBR and no more. You have to make sure your insurance company explicitly knows what those are, and covers the stored value of the VST plugins and other items that are on the dongle.
A car example: If someone steals a key to a vehicle, the insurance company might reimburse for the lost piece of metal, but likely not cover the reprogramming of the PATS system to allow that key to work in the ignition.
Don't forget inconvenience. Losing a dongle can be worse than losing a computer. With a lost laptop, assuming decent backups using Time Machine or even Mozy/Carbonite/Backblaze, the data and apps can be restored and work can continue. No music software means the gig is dead in the water without alternate plans.
From what I have seen with Steinberg's stuff, I have not encountered any musicians who really like it. First, there is the dongle/VST plugin aspect. Start setting up at a gig, and some crackhead makes off with your dongle? From what I know, a musician either has to hit the warez/crack sites, or re-buy everything. To prevent this from happening, I have had made at a metal shop custom 1U locking rack drawers that had a powered USB hub mounted in the back, just so people could have their license key stuff secured at a concert.
I wonder why Steinberg continues to do dongles, especially with pro-quality tools like ACID Pro on the Windows side, and Logic Studio on the Mac side being so relatively inexpensive. The only way I see Steinberg's offerings being relevant these days is if someone needed a certain VST plugin that didn't work on other VST hosts.
I'd add four things to using a VM for untrusted stuff:
1: Roll back the VM, back it up if you so choose, then run Windows/Microsoft update and update the other programs at least monthly. Then back up the .vmdk files again.
2: Buy a copy of sandboxie for the VM. This way, the malicious software would have to get through that before being able to use kernel level abilities in case there is a 0-day to allow malware to get out past the hypervisor.
3: Run the potentially nasty stuff as a user with no admin rights. Bonus points for running DropMyRights for even less privileges given to the process.
4: Use a proxy (or at least yank the VM's access to the network), so if stuff phones home, it doesn't have your real IP address.
Untrusted stuff isn't just keygens. I tend to run tools which I download for one purpose in a VM just so I know they do the job at hand with a file, and no more. For example, if I'm using a utility I downloaded to strip off the EXIF data from a number of pictures for privacy reasons, I stick the pictures in the VM, run the utility, power off the VM, mount the disk image, yank off the processed photos, unmount the image, and then roll it back. This way, if the utility were malicious, the only persistent data it could affect would be the picture files.
Exactly. For example, any machines I have which have to have an Internet facing ssh port are definitely not going to be accepting passwords. Tools like ssh-guard are nice, but it isn't hard for a determined attacker to just keep coming from different IP ranges. To add a little bit of security, port knocking is a nice ability to have, just so an attacker doesn't see an open port to start having fun with.
What would be ideal is if OATH support would advance to the point where I can just enter my username, then my password and then the random key from a SecurID or other token. This way, an attacker would have to go from passively looking at passwords as they float by to actively MITM-ing the connection.
Tata is making subcompacts in India which use this exact method as a propulsion source to get around. However, what works over there might not work over here.
But, if the technology makes it over, just the fact that it can keep a vehicle running with the gasoline or diesel engine off at idle to low speeds in city traffic would save a good amount of fuel.
There are a lot of places other than FB which don't encrypt their traffic other than the initial username/password. Mainly because it is cheap to do so (plain http connections after authentication can be cached, no need to set up and tear down encrypted sockets, etc.)
However what was par for security even last year before widespread sidejacking tools like FireSheep became available is now considered a wide open security risk. Just like how companies have to firewall their networks with the expense involved in having network security, separating departments, and such, companies will have to move to SSL for the entire transaction with their visitors or customers.
+1. I know FB would rake in the bucks if they offered a premium service that had https by default, no ads, and the ability to use a VASCO or SecurID keyfob (with OATH certification when logging from PCs, and for non-PCs, the FB app has the ability to set a PIN.)
I'd pay the usual $20 a year for this easily, mainly because FB is a good tool for keeping track of band and other events going on locally.
True, a power station would be more straightforward. However, fewer people would consider that a fuel refinery would actually be running a cheap energy source in the basement than a power station. The trick is to use a pipeline as opposed to actual freight shipping, so nobody is the wiser that the pipeline has not has anything run through it. Easier on the books that way.
There are plenty of other places where people wouldn't be looking for a man behind the curtain: Even a data center which sits in the middle of nowhere with several 120VAC connections to the grid (need that redundancy) might be plausible, assuming someone who isn't versed in electricity doesn't show up and wonder how a few 480VAC transformers (that have not been touched since a mobile home park necessitated their installation in the 1970s) are handling the complete load of a facility using 20-30 megawatts.
If one really wanted to keep the technology secret, but still make a profit from it, one could just create an oil "refinery" that makes and sells gasoline. Yes, it might have incoming pipes from an upstream source, but those pipes never have been turned on. The oil is paid for but the upstream seller has never bothered to deliver on it. In reality, the gasoline being sold from the "refinery" would be CO2 pulled out of the air, dumped through a ton of energy expensive chemical processes, and then dumped in the semis ready to haul to the local 7-11 pump. It doesn't matter how expensive energy-wise the reactions would be.
Result: A decent profit, nobody ever the wiser (except the oil seller upstream who has to keep it secret why they sell oil to someone, but in reality they have not even opened the pipeline to deliver a gallon), and definitely nobody would suspect a cheap energy source. Combine it with the energy source powering up the reactor, and one has a carbon-negative business.
There is also the fact that one has to get a CHL (concealed handgun license) in either revolver or semi-auto, and have to carry the right firearm for the license.
I'd agree that Texas used to be on the bottom of the list, but has moved up. However, don't let the talk about "castle doctrine" and other laws fool people. There are a good number of people who are going to spend a good chunk of their lives (if not the rest of it) in TDCJ prisons because they did not understand the law and have taken potshots at either someone breaking into a neighbor's property, someone who cut them off on the highway, or someone that looked suspicious.
If auto makers could use those "smart screws" that flip between open and shut, they could. Mainly because it would allow ease of making stuff without worry about tool paths.
However, these devices have one flaw -- a battery powerful and reliable enough to allow the fastener to pop open after 10-20 years in the field when it comes time to service something.
Perhaps, we will see cases held together by solenoids that only retract after the right code is entered to the software. However, there are always bugs. For example, some old Compaq workstations had a solenoid case lock as an option. Of course, if the battery in the case went out, or the keyboard controller died, it would take the manual method; Compaq bundled a screwdriver that you used to take the three screws holding in the solenoid lock, and you would open the case as normal.
What a fair compromise would be is Motorola having a model of phone just for the modder crowd. Hell, charge full price and have it unlocked. Sell it as the hacker's dream toy, similar to a N900 where (assuming it came with decent specs), people can go ape with it, and have it do new and cool things.
It doesn't just have to be aimed at the percent of the buyers who just mod. Aim it at people who are tech savvy and/or creative. If someone buys it and keeps it stock, unrooted, with full MotoBLUR, that's great. If someone else fastboot oem-unlocks it to stick a full Debian distro on it, rock on.
That is the rub. I've learned that the ONLY handsets which will guarantee ROM updating will be Google's reference models, the ADP1, ADP2, Nexus 1, and Nexus S.
What I'm hoping for is that Google can get a reference model made for Honeycomb that has a decent sliding keyboard and a MicroSD card slot. 24 GB just doesn't cut it, and even then, it is nice to be able to stick a card in, nandroid backup your ROM and titanium backup all your apps before hitting the road for a long trip with the SD card that holds all your MP3s.
I just hope the Nexus S's successor has at least has SDXC card capability. If not, guess it will be time to wait for the reference model when Ice Cream goes GA.
I'd love to see that technology become common in the US for a completely different reason, and that is to separate work data and home data. Combine this with virtualization, and this would be great for people who use their devices for work and home stuff. Leave a job and the IT staff sends a self-destruct signal? It only gets rid of the work based VM.
Done right, it can be made decently secure as well.
Of course, having the ability to switch SIMs for one machine is cool too, not just for cheap call rates. Say provider "A" is 4G but has a pathetic limit, provider "B" has 4G, but charges fees after a gig or two, and provider "C" is 3G, but is unlimited. The phone can use provider "A" until the bandwidth is exhausted, switch to provider "B", then to "C", until the month resets and "A" is useful again. Add QoS so important traffic (E-mail) goes over one link and other stuff goes over another, and this would be a very good thing (tm) to have.
Even more ironic -- the providers in Asia use R/UIM cards, which are functionally identical in size and shape to SIM cards, but are for CDMA networks. Combine this with a radio that handles CDMA and GSM, and even the US's big divide between providers can be bridged to allow one device to work anywhere. Hopefully everyone adapting LTE will make the need for SIM versus R/UIM cards not needed, but who knows. I'm afraid the CDMA providers won't use SIM technology when LTE comes online, so even if a device is LTE based, a provider can just say no when a customer calls and begs for it to be activated.
I'd like to see more phones have the option to completely erase contents after "X" period of time with no network signal. This way, someone can't just pull a SIM card to keep access.
As for remote wipes, sometimes phones do provide non-corporate customers the way to do this. Apple does, (you used to need a .me.com account, but apparently with iOS 4.2.1, not anymore.) Motorola's Motoblur accounts also have this ability as well.
I do think having E-mail with an Exchange provider (that supports OWA) is a good thing even with these options, just because of the ability to wipe the contents using a different mechanism.
If I stuck a deadbolt cylinder on a hollow core door used for internal rooms, someone could easily kick it in without a moment's thought.
If I stuck a cylinder on a European lock that had multipoint locking, a solid jamb that uses steel rails that are sunk into the foundation, it would require a hydraulic ram to open it.
Similar with phones. If I stuck a PIN on an open device, there would be ways to get around it. However, if the device was built from the ground up with encrypted filesystems, keys in a secure RAM partition, and anti-brute force code where PIN guessing resulted in longer delays, and eventually a complete zeroization of the device, the same PIN that might be worthless on one device may adequately protect another.
One can see this when comparing a TrueCrypt keyfile stored on a cryptographic token (or an IronKey) compared to one stored on a generic USB flash drive. After try #20 with the USB flash drive, it doesn't matter, especially if one just copies the cyphertext to another image to protect against self destruct software. The same data stored on a hardware device using hardware encryption will be long gone before attempt #20 could even be made.
A 4 digit PIN can be excellent protection, or it can be a joke depending on how the device is architected.
Very true. If SHA-X was secure for the foreseeable future, there wouldn't be a contest going on for someone to make a replacement algorithm for the SHA-3 name. In the meantime, it would be nice for Whirlpool, Skein, or another well tested hash function to take up the slack.
However, the hash functions are open for all to look at. This beats someone stuffing all the data into an 8 bit LFSR, yanking 128 bits out and calling that a cryptographically secure hash.
Exactly. The usual solution is to have something like a McAfee command line scanner [1]. Then cron it up every so often to do a file scan when absolutely nothing is going on. In reality, this is only useful for samba servers, but because for CYA reasons, I have it scan everything else every so often.
[1]: Careful on an update script -- http://www.lolware.net/uvscan.html
Hrm... when it comes to numbers of compromised devices, both the iPhone and Android have not had any real intrusions (other than some jailbroken devices with the root password still set to "alpine" and sshd enabled.)
The security mechanisms of both operating systems are both pretty open. Android uses the Dalvik VM to sandbox, and Linux's user level protection to keep apps in their directories. iOS uses chroot() and the mobile user to enforce its security. Which is better? This can be argued endlessly. Both are quite good.
So why is this guy saying Android is insecure? If he knows something that is a fundamental flaw in Android's design, he should state it, otherwise, he is espousing FUD.
In the 1990s, there were a lot of people who made their own encryption algorithms, of course they were "secret" for their own encryption products. Not surprisingly, a lot of them were just using rand() with the password the user types in as the seed for srand() and then XOR-ing the data. To the casual user, random cyphertext is random cyphertext. However, it doesn't take long to spin through 65536 possibilities for a seed.
Of course, we had Clipper/Skipjack. I'd dread what life would be like if we had to trust the encryption on that chip (without knowing anything about the algorithm), and nevermind who had access to the LEAF fields. Probably most of the /. readers would have found a way to zero out the LEAF fields so the key couldn't be pulled out of escrow.
I'm just glad we have decent, open cryptographic standards. If a product doesn't use AES with a good implementation other than ECB, find something that does. RSA and SHA1 are not perfect, but so far, they have been secure.