Trust means a lot of things. If a CA engages in writing deliberately fake certificates so one nation can hijack or commit online trespass by intercepting data that they otherwise should not have, the CA is not trustworthy, and should be expunged from browsers.
This applies to all CAs. If Verisign handed out fake certs so people can intercept bank traffic, their certs should be yanked out of Web browsers. A CA's core job is to assure that to the best of their ability that someone they say is foo.com is in reality foo.com, and not blackhat.com. It doesn't matter what the reason a CA wouldn't not do this. If they hand over intermediate keys to an eavesdropper, they have fundamentally failed in their duty.
I agree with you that maybe a site should pop up a warning before sending info. However, a site with no SSL is just as vulnerable as a site with a self signed key. (This is in contrast to a key that is invalid where it might be hanky-panky in play as opposed to just a SS cert.)
Another use for a SS cert is to ward off two basic types of attack: The guy sniffing a WAP, who likely won't be able to actively intercept the connection. And the Phorm ad-generators whose job it is to insert ads into ongoing streams of traffic. Because those handle so much traffic, it would take a large machine to do the calculations to commit to creating and tearing down SSL tunnels to MITM traffic to sites.
So, even though it doesn't give a solid chain of trust, self signed certs do provide a form of security.
I'd disagree about self signed certificates. Yes, they can be MITM-ed, but they do provide some form of security to keep the traffic encrypted. At the minimum, it keeps Phorm-like ad-spewers out.
I would like to see Web browsers not go ape over a self-signed cert (as opposed to certs that don't match). Instead mark the connection as insecure, but with some basic anti-snooping provision, so people understand the connection isn't secure completely, but Joe Script Kiddie with his wireless packet sniffer can't snag someone's password to a website that uses self-signed certs.
This way, average users don't see a lock icon and assume the connection is secure, but more knowledgeable users know that SSL is in use, even though MITM attacks are doable.
I'd like to see more work with peltiers, but IIRC, they take a lot of energy to do their job of moving heat to one side, something that CPUs are already tight on.
x86 and amd64 have an installed base. Itanium doesn't. This doesn't mean x86 is any better than Itanium, in the same way that Britney Spears is better than $YOUR_FAVORITE_BAND because Britney has sold far more albums.
Intel has done an astounding job at keeping the x86 architecture going. However, there is only so much lipstick you can put on a 40 year old pig.
Very true, but it eventually needs to be done. You can only get so big with a jet engine that is strapped onto a biplane. The underlying architecture needs to change sooner or later. As things improve, maybe we we will get to a point where we have CPUs with enough horsepower to be able to run emulated amd64 or x86 instructions at a decent speed. The benefits will be many by doing this. First, in assembly language, we will save a lot of instructions because programs will have enough registers to do actions at once, rather than keep shuttling data to and from RAM to complete a calculation. Having few access to and from RAM will speed up tasks immensely because register access is so much faster. Take a calculation that adds up a bunch of numbers. The numbers can be loaded into separate registers, added, result dropped back into RAM. With the x86, it would take a lot of load and stores to do the same thing.
At the extreme, maybe it might be time for a new CPU architecture? Intel has been doing so much stuff behind the scenes to keep the x86 architecture going, that it may be time to just bite the bullet and move to something that doesn't require as much translation?
Itanium comes to mind here because it offers a dizzying amount of registers, both FPU and CPU available to programs. To boot, it can emulate x86/amd64 instructions.
Virtual machine technology is coming along rapidly. Why not combine a hardware hypervisor and other technology so we can transition to a CPU architecture that was designed in the past 10-20 years?
I have a feeling that once doing smaller and smaller lines becomes prohibitive, we will see a return to either revving up the clock speed (if possible), or adding more cores per die. Maybe even adding more discrete CPUs, so a future motherboard may have multiple CPUs on it similar to how mid to upper range PCs ended up with multiple procs present around 2000-2001.
There are always more ways to keep going with Moore's law if one item gets near exhausted.
Since the big names are always whining about piracy on the PC platform, why can't they just completely move to consoles, and shut their traps? I guess they don't want to leave the PC platform to Blizzard and the indies.
As for pirating, what I've seen is the simplest and best way to deal with that is to have a CD key for multiplayer, and only how many instances of the key are allowed per license. Local stuff will end up being cracked anyway, so why even bother. Might as well offer online content and online servers, not bother battling the die-hard pirates, and spend the money making a better game.
I am showing my age, but with all the sequels on sequels on the market, I wonder if a company like Origin could ever come to fruition again with fresh gameplay, characterization, and plot. Something better than just another FPS with more polys and more mutated zombies.
On a non-JB iOS device, root is well protected. Or enough that a password isn't going to help things. By default, the iPhone doesn't have much of a userland, which is why a JB takes a bit because of downloading the basic stuff like a shell, dkpg, and other necessities before Cydia shows up.
Of course, once the device is jailbroken, the user should change the root and mobile PW. I do wish Cydia would have this functionality built in, especially after the install of OpenSSH.
As a side note, Android has no root password, but it remains decently secure.
Very true. However, say the accountholder is in country "A". His friends are in other places around the globe. If he bites it, it would be difficult for his friends to get a death cert from another nation, then send it in, compared to everyone assenting that the person is dead, and rebuilding a private key.
This is assuming people one trusts have access to such stuff. As soon as a person dies, safe deposit boxes get frozen, and it takes a probate judge to un-freeze those. Same with safes on people's property.
Plus, people I might trust may not be close geographically.
Ideally, it would be nice to have a secret key sharing system (Shamir's Secret Sharing is a popular algorithm), where the key is reconstituted, where X out of Y total people need to think the person is dead before the key can be regenerated and the account accessed.
Maybe it would be nice for social networking services to have a "key escrow" feature, or some way where trusted people who know the person can validate the account as dead automatically and have it disabled, similar to having key revokers in PGP that can yank a public key if the private key gets lost.
This feature would be up to the discretion of the individual, because this could be quite easily abused.
If someone does not want to jailbreak (JB-ed devices can use the dev team PDF exploit patch on Cydia), I actually recommend a (somewhat roundabout and completely destructive) process in updating to 4.0.2:
1: Use TinyUmbrella to save the SHSH blobs. You might want to go back to 4.0.1 sometime in the future. 2: Plug device in to your *primary* computer, don't download the latest patch yet. Sync it, back it up, and all that, so you can remove everything off the device. 3: DFU restore the phone. While the phone is plugged in and iTunes is up, hold down the Home key, and then press the on/off button for 10 seconds, then let up on the on/off button, while keeping the Home button down. 4: Restore the phone. Let iTunes download the update to 4.0.2 and re-install all apps and data.
The reason I recommend this method is that should the phone actually have gotten compromised with some botnet client, the DFU restore would have completely erased all malware that might have been running if the PDF exploit was used for bad things. Of course, you will lose your JB and unlock, as well as the ability to re-jailbreak with this method, but it makes sure that there is nothing that might be trying to ninja-call 1-900 numbers to give some blackhat in Elbonia a supplemental income source.
The problem is that you may know what you are doing, the average Slashdot reader may know what they are doing, but the majority of the people who buy smartphones would have no clue the ramifications of a "#" prompt on their device.
This is why I hope that Apple addresses app piracy via a different mechanism than keeping the walls of the walled garden up. Something that makes it difficult enough to keep Joe Sixpack from rooting/JBing their device, but easy enough for a person with a semblance of a clue to do it.
For example, rooting the Droid X without using the one click app. For anyone who has UNIX experience, it is simple... copy the exploit, run it, copy su and the app that goes with it, continue on. However, for Joe Sixpack who thinks UNIX are guys who sing in high pitched voices, it keeps him from getting root. This is a good thing, as it solves the dancing bunny problem.
If Joe Sixpack gets root, malicious apps can get root, and Joe Sixpack will then blame/sue Google, the maker of the cellphone, and the cellular provider for not being secure enough.
I just wish that Apple would put a mechanism in similar to what Android has in place where apps can go validate they are licensed to run on the device, and if not, don't run, or point the user to the App Store to buy a licensed copy. This way, the security of apps won't be reliant on keeping users from JB-ing their devices.
With Google's new API to check if an app is licensed, pirates have to hack each app, one by one, in order to get them working on unauthorized phones. Maybe Apple can follow suit, so people who like a "#" sign prompt on their phone can have it, but the pirates will be fighting an uphill battle.
A rooted Android phone is almost always still decently secure, and usually the rooting process involves something with adb, something a Dalvik VM app will be hard pressed to get unless it asks for permissions.
Say a piece of malware gets downloaded from Google's Marketplace. The su app pops up asking, "hey, the Vomitron Toaster app wants root privs?" Anyone with a clue is going to tick "no" and "remember this decision". In a couple hours after the app gets flagged, Google fires off the kill switch and the app gets zapped from the store and phones.
Rooting gives one more functionality, but it doesn't significantly add functionality to a device like an IOS JB does.
Here is the funny thing. If I want a command line shell to do stuff on a phone, Android is easy -- download a terminal app. The iPhone, I need to do the following:
1: JB the device. 2: Hunt down "MobileTerminal 426", the Debian package. 3: Get on a wireless network. 4: Enable OpenSSH. 5: ssh into phone, change root and mobile password to something respectable (20+ characters.) 6: scp the Debian package and install it. 7: Install sudo from Cydia and configure it so I don't need to type in the insanely long password when I want root access. 8: Edit/etc/sshd/sshd_config to only allow access via RSA key, and disallow root access. 9: Make sure the sshd is turned off in SBSettings unless it is needed. It will turn back on after a reboot.
All this so I can have full command line access to my iPhone and a method of copying files to and from the filesystem without restriction. The reason why I do the gymnastics with sshd as opposed to uninstalling it is so I can sftp in.
To boot, the only command line terminal app [1] that works on the iPhone (the Terminal app in Cydia is not iOS4 compatible and crashes on startup) doesn't seem to have the ability to do control keys other than control-C. Of course, I wonder if I can just use a normal app and ssh to loopback, but so far, that hasn't worked unless the device is on a Wi-Fi network.
Personally, if someone can make a good terminal emulator and put it on Cydia, I'd pay $5-$10 for it. Especially if it has an easy mechanism for doing control and meta keys, so if I feel insane enough to run emacs, I can.
[1]: A true terminal app that uses a shell and such. There are apps for ssh and such, but those don't have access to the whole phone's filesystem, and I doubt they would get approved if they had the ability to do so.
I'd augment Backblaze by having some form of backup on your LAN. It could be a directly attached HDD, a NAS, a tape drive, or something along those lines. This way, when something happens, it is a lot faster to fetch the 1-2TB on your system from an external HDD than it is to wait for the stuff to be re-downloaded via a cloud though a slow pipe.
Plus, there is always the fact that nothing is 100%. One never knows if the backup cloud provider may go down, so storing all one's eggs in that basket may not be a good idea.
Key storage is simple... create a directory on the onboard flash, store a 256 bit nonce from/dev/urandom in there. Then use that to encrypt the EncFS or LUKS image. This way, someone can recover it who is authorized, while on a hard reset, this directory is purged and recreated so the old key is gone. Bonus points in having specific memory "cells" dedicated to storing encryption keys similar to what eTokens have that are easily and thoroughly wiped (no need to worry about wear leveling or data relocation.)
I agree 100% with you, and this is Android's biggest obstacle to replacing Windows Mobile devices and Blackberries in the enterprise.
The two security features I really want to see as pasts of the Android OS are the ability to wipe parts, and the ability to encrypt data. Android 2.2 encrypts apps stored on the SD card, but what I would like to see is the ability to use file by file encryption with EncFS, or encrypt the whole memory card as a block image, using LUKS. This way, if the Android device is hard reset and the encryption keys purged, there wouldn't be a way for the SD card to be useful if the phone falls into the wrong hands.
My Cliq with Android 1.6 had the ability to use a PIN lock. Ideally, it would be nice to have 4-5 types of lock options:
1: Pick x amount of pictures from a 3x3 or 4x4 array. The pictures will be randomly placed, and the user just selects the ones he or she has marked, and either 1 or more will show up.
2: Normal PIN.
3: Password entry. I know some people who have sensitive enough information that a solid password is a must. Perhaps have the option for the keys to be randomly placed.
4: Click places in a picture. Have the user have 3-4 pictures that he or she has marked certain spots to select.
5: An additional authentication mechanism like a fingerprint scanner. The one thing people need to remember about fingerprint scanners -- they are more of a username replacement, not a password replacement.
Very true. The trick is to limit the guesses someone can make. I just wish Android would have the ability to wipe itself after x amount of failed attempts. Blackberries have this, the iPhone does. My old Windows Mobile device even has this functionality. The only way I've seen to do this in Android is to use a third party utility like WaveSecure,
In a way you are right. A software approximation of this technology is having a RAMdisk, creating a TC volume on the hard disk that stores the keyfile on the RAMDisk, and when the machine is rebooted, the old TC volume and the keyfile that unlocks it is recreated.
I can see this used not just in copiers where temporary files need to be zapped for privacy reasons, but in a number of other places:
1: Photo kiosks. 2: Documents stored on public access computers. 3: Medical terminals used for X-ray viewing. 4: Cash register terminals for storing CC data. 5: CCTV DVRs. If a video time frame needs flagged for long term copying, it is. 6: Proxy/sendmail log servers where logs don't have to be kept for longer than it takes to check if there is an intrusion. 7: Temporary scratch space for a database server, say to pack and unpack normally encrypted BLOB/CLOB data. 8: A special hard disk just for/tmp. If one thinks about it, this type of HDD is absolutely perfect for the/tmp filesystem in the classic sense of it being zeroed out on reboot. 9: Temporary scratch space when unarchiving data and putting it on a secure partition or tape drive. For example, getting data from tape or another site, storing it temporarly to get a machine to restore locally. 10: A machine set up and automatically imaged for guests to browse the Web. 11: A machine set up and autoimaged in a student computer lab. This way, a power cycle ensures that private data is not recoverable from the previous student. 12: Drives set up for swap. This way, a power cycle removes all traces of a virtual machine's paging. 13: Community clouds, where a VM is cloned to the drive, used to give better capacity, then shut down and the drive cycled so the next user on that drive doesn't have access to the previous user's data. 14: A place to decode encryption keys temporarly pulled out of a HSM to be copied to another source. 15: Airport X-day machines so the private pictures of people stay private.
Flash shared objects is the main thing. Easy fix -- download and use the BetterPrivacy extension.
Of course, the absolute sure way to ensure browser privacy is to have a virtual machine dedicated to browsing, and have it roll back to the last snapshot once done. This is easy to do in Windows 7 and XP Mode. This way, some cookies left behind by some third party add-on (Java, Flash, or W/E) are eradicated completely.
Slashdot Mirror
Trust means a lot of things. If a CA engages in writing deliberately fake certificates so one nation can hijack or commit online trespass by intercepting data that they otherwise should not have, the CA is not trustworthy, and should be expunged from browsers.
This applies to all CAs. If Verisign handed out fake certs so people can intercept bank traffic, their certs should be yanked out of Web browsers. A CA's core job is to assure that to the best of their ability that someone they say is foo.com is in reality foo.com, and not blackhat.com. It doesn't matter what the reason a CA wouldn't not do this. If they hand over intermediate keys to an eavesdropper, they have fundamentally failed in their duty.
I agree with you that maybe a site should pop up a warning before sending info. However, a site with no SSL is just as vulnerable as a site with a self signed key. (This is in contrast to a key that is invalid where it might be hanky-panky in play as opposed to just a SS cert.)
Another use for a SS cert is to ward off two basic types of attack: The guy sniffing a WAP, who likely won't be able to actively intercept the connection. And the Phorm ad-generators whose job it is to insert ads into ongoing streams of traffic. Because those handle so much traffic, it would take a large machine to do the calculations to commit to creating and tearing down SSL tunnels to MITM traffic to sites.
So, even though it doesn't give a solid chain of trust, self signed certs do provide a form of security.
I'd disagree about self signed certificates. Yes, they can be MITM-ed, but they do provide some form of security to keep the traffic encrypted. At the minimum, it keeps Phorm-like ad-spewers out.
I would like to see Web browsers not go ape over a self-signed cert (as opposed to certs that don't match). Instead mark the connection as insecure, but with some basic anti-snooping provision, so people understand the connection isn't secure completely, but Joe Script Kiddie with his wireless packet sniffer can't snag someone's password to a website that uses self-signed certs.
This way, average users don't see a lock icon and assume the connection is secure, but more knowledgeable users know that SSL is in use, even though MITM attacks are doable.
I'd like to see more work with peltiers, but IIRC, they take a lot of energy to do their job of moving heat to one side, something that CPUs are already tight on.
x86 and amd64 have an installed base. Itanium doesn't. This doesn't mean x86 is any better than Itanium, in the same way that Britney Spears is better than $YOUR_FAVORITE_BAND because Britney has sold far more albums.
Intel has done an astounding job at keeping the x86 architecture going. However, there is only so much lipstick you can put on a 40 year old pig.
Very true, but it eventually needs to be done. You can only get so big with a jet engine that is strapped onto a biplane. The underlying architecture needs to change sooner or later. As things improve, maybe we we will get to a point where we have CPUs with enough horsepower to be able to run emulated amd64 or x86 instructions at a decent speed. The benefits will be many by doing this. First, in assembly language, we will save a lot of instructions because programs will have enough registers to do actions at once, rather than keep shuttling data to and from RAM to complete a calculation. Having few access to and from RAM will speed up tasks immensely because register access is so much faster. Take a calculation that adds up a bunch of numbers. The numbers can be loaded into separate registers, added, result dropped back into RAM. With the x86, it would take a lot of load and stores to do the same thing.
At the extreme, maybe it might be time for a new CPU architecture? Intel has been doing so much stuff behind the scenes to keep the x86 architecture going, that it may be time to just bite the bullet and move to something that doesn't require as much translation?
Itanium comes to mind here because it offers a dizzying amount of registers, both FPU and CPU available to programs. To boot, it can emulate x86/amd64 instructions.
Virtual machine technology is coming along rapidly. Why not combine a hardware hypervisor and other technology so we can transition to a CPU architecture that was designed in the past 10-20 years?
I have a feeling that once doing smaller and smaller lines becomes prohibitive, we will see a return to either revving up the clock speed (if possible), or adding more cores per die. Maybe even adding more discrete CPUs, so a future motherboard may have multiple CPUs on it similar to how mid to upper range PCs ended up with multiple procs present around 2000-2001.
There are always more ways to keep going with Moore's law if one item gets near exhausted.
Since the big names are always whining about piracy on the PC platform, why can't they just completely move to consoles, and shut their traps? I guess they don't want to leave the PC platform to Blizzard and the indies.
As for pirating, what I've seen is the simplest and best way to deal with that is to have a CD key for multiplayer, and only how many instances of the key are allowed per license. Local stuff will end up being cracked anyway, so why even bother. Might as well offer online content and online servers, not bother battling the die-hard pirates, and spend the money making a better game.
I am showing my age, but with all the sequels on sequels on the market, I wonder if a company like Origin could ever come to fruition again with fresh gameplay, characterization, and plot. Something better than just another FPS with more polys and more mutated zombies.
On a non-JB iOS device, root is well protected. Or enough that a password isn't going to help things. By default, the iPhone doesn't have much of a userland, which is why a JB takes a bit because of downloading the basic stuff like a shell, dkpg, and other necessities before Cydia shows up.
Of course, once the device is jailbroken, the user should change the root and mobile PW. I do wish Cydia would have this functionality built in, especially after the install of OpenSSH.
As a side note, Android has no root password, but it remains decently secure.
Very true. However, say the accountholder is in country "A". His friends are in other places around the globe. If he bites it, it would be difficult for his friends to get a death cert from another nation, then send it in, compared to everyone assenting that the person is dead, and rebuilding a private key.
This is assuming people one trusts have access to such stuff. As soon as a person dies, safe deposit boxes get frozen, and it takes a probate judge to un-freeze those. Same with safes on people's property.
Plus, people I might trust may not be close geographically.
Ideally, it would be nice to have a secret key sharing system (Shamir's Secret Sharing is a popular algorithm), where the key is reconstituted, where X out of Y total people need to think the person is dead before the key can be regenerated and the account accessed.
Maybe it would be nice for social networking services to have a "key escrow" feature, or some way where trusted people who know the person can validate the account as dead automatically and have it disabled, similar to having key revokers in PGP that can yank a public key if the private key gets lost.
This feature would be up to the discretion of the individual, because this could be quite easily abused.
If someone does not want to jailbreak (JB-ed devices can use the dev team PDF exploit patch on Cydia), I actually recommend a (somewhat roundabout and completely destructive) process in updating to 4.0.2:
1: Use TinyUmbrella to save the SHSH blobs. You might want to go back to 4.0.1 sometime in the future.
2: Plug device in to your *primary* computer, don't download the latest patch yet. Sync it, back it up, and all that, so you can remove everything off the device.
3: DFU restore the phone. While the phone is plugged in and iTunes is up, hold down the Home key, and then press the on/off button for 10 seconds, then let up on the on/off button, while keeping the Home button down.
4: Restore the phone. Let iTunes download the update to 4.0.2 and re-install all apps and data.
The reason I recommend this method is that should the phone actually have gotten compromised with some botnet client, the DFU restore would have completely erased all malware that might have been running if the PDF exploit was used for bad things. Of course, you will lose your JB and unlock, as well as the ability to re-jailbreak with this method, but it makes sure that there is nothing that might be trying to ninja-call 1-900 numbers to give some blackhat in Elbonia a supplemental income source.
The problem is that you may know what you are doing, the average Slashdot reader may know what they are doing, but the majority of the people who buy smartphones would have no clue the ramifications of a "#" prompt on their device.
This is why I hope that Apple addresses app piracy via a different mechanism than keeping the walls of the walled garden up. Something that makes it difficult enough to keep Joe Sixpack from rooting/JBing their device, but easy enough for a person with a semblance of a clue to do it.
For example, rooting the Droid X without using the one click app. For anyone who has UNIX experience, it is simple... copy the exploit, run it, copy su and the app that goes with it, continue on. However, for Joe Sixpack who thinks UNIX are guys who sing in high pitched voices, it keeps him from getting root. This is a good thing, as it solves the dancing bunny problem.
If Joe Sixpack gets root, malicious apps can get root, and Joe Sixpack will then blame/sue Google, the maker of the cellphone, and the cellular provider for not being secure enough.
I just wish that Apple would put a mechanism in similar to what Android has in place where apps can go validate they are licensed to run on the device, and if not, don't run, or point the user to the App Store to buy a licensed copy. This way, the security of apps won't be reliant on keeping users from JB-ing their devices.
With Google's new API to check if an app is licensed, pirates have to hack each app, one by one, in order to get them working on unauthorized phones. Maybe Apple can follow suit, so people who like a "#" sign prompt on their phone can have it, but the pirates will be fighting an uphill battle.
A rooted Android phone is almost always still decently secure, and usually the rooting process involves something with adb, something a Dalvik VM app will be hard pressed to get unless it asks for permissions.
Say a piece of malware gets downloaded from Google's Marketplace. The su app pops up asking, "hey, the Vomitron Toaster app wants root privs?" Anyone with a clue is going to tick "no" and "remember this decision". In a couple hours after the app gets flagged, Google fires off the kill switch and the app gets zapped from the store and phones.
Rooting gives one more functionality, but it doesn't significantly add functionality to a device like an IOS JB does.
Here is the funny thing. If I want a command line shell to do stuff on a phone, Android is easy -- download a terminal app. The iPhone, I need to do the following:
1: JB the device. /etc/sshd/sshd_config to only allow access via RSA key, and disallow root access.
2: Hunt down "MobileTerminal 426", the Debian package.
3: Get on a wireless network.
4: Enable OpenSSH.
5: ssh into phone, change root and mobile password to something respectable (20+ characters.)
6: scp the Debian package and install it.
7: Install sudo from Cydia and configure it so I don't need to type in the insanely long password when I want root access.
8: Edit
9: Make sure the sshd is turned off in SBSettings unless it is needed. It will turn back on after a reboot.
All this so I can have full command line access to my iPhone and a method of copying files to and from the filesystem without restriction. The reason why I do the gymnastics with sshd as opposed to uninstalling it is so I can sftp in.
To boot, the only command line terminal app [1] that works on the iPhone (the Terminal app in Cydia is not iOS4 compatible and crashes on startup) doesn't seem to have the ability to do control keys other than control-C. Of course, I wonder if I can just use a normal app and ssh to loopback, but so far, that hasn't worked unless the device is on a Wi-Fi network.
Personally, if someone can make a good terminal emulator and put it on Cydia, I'd pay $5-$10 for it. Especially if it has an easy mechanism for doing control and meta keys, so if I feel insane enough to run emacs, I can.
[1]: A true terminal app that uses a shell and such. There are apps for ssh and such, but those don't have access to the whole phone's filesystem, and I doubt they would get approved if they had the ability to do so.
I'd augment Backblaze by having some form of backup on your LAN. It could be a directly attached HDD, a NAS, a tape drive, or something along those lines. This way, when something happens, it is a lot faster to fetch the 1-2TB on your system from an external HDD than it is to wait for the stuff to be re-downloaded via a cloud though a slow pipe.
Plus, there is always the fact that nothing is 100%. One never knows if the backup cloud provider may go down, so storing all one's eggs in that basket may not be a good idea.
Key storage is simple... create a directory on the onboard flash, store a 256 bit nonce from /dev/urandom in there. Then use that to encrypt the EncFS or LUKS image. This way, someone can recover it who is authorized, while on a hard reset, this directory is purged and recreated so the old key is gone. Bonus points in having specific memory "cells" dedicated to storing encryption keys similar to what eTokens have that are easily and thoroughly wiped (no need to worry about wear leveling or data relocation.)
I agree 100% with you, and this is Android's biggest obstacle to replacing Windows Mobile devices and Blackberries in the enterprise.
The two security features I really want to see as pasts of the Android OS are the ability to wipe parts, and the ability to encrypt data. Android 2.2 encrypts apps stored on the SD card, but what I would like to see is the ability to use file by file encryption with EncFS, or encrypt the whole memory card as a block image, using LUKS. This way, if the Android device is hard reset and the encryption keys purged, there wouldn't be a way for the SD card to be useful if the phone falls into the wrong hands.
My Cliq with Android 1.6 had the ability to use a PIN lock. Ideally, it would be nice to have 4-5 types of lock options:
1: Pick x amount of pictures from a 3x3 or 4x4 array. The pictures will be randomly placed, and the user just selects the ones he or she has marked, and either 1 or more will show up.
2: Normal PIN.
3: Password entry. I know some people who have sensitive enough information that a solid password is a must. Perhaps have the option for the keys to be randomly placed.
4: Click places in a picture. Have the user have 3-4 pictures that he or she has marked certain spots to select.
5: An additional authentication mechanism like a fingerprint scanner. The one thing people need to remember about fingerprint scanners -- they are more of a username replacement, not a password replacement.
Very true. The trick is to limit the guesses someone can make. I just wish Android would have the ability to wipe itself after x amount of failed attempts. Blackberries have this, the iPhone does. My old Windows Mobile device even has this functionality. The only way I've seen to do this in Android is to use a third party utility like WaveSecure,
In a way you are right. A software approximation of this technology is having a RAMdisk, creating a TC volume on the hard disk that stores the keyfile on the RAMDisk, and when the machine is rebooted, the old TC volume and the keyfile that unlocks it is recreated.
I can see this used not just in copiers where temporary files need to be zapped for privacy reasons, but in a number of other places:
1: Photo kiosks. /tmp. If one thinks about it, this type of HDD is absolutely perfect for the /tmp filesystem in the classic sense of it being zeroed out on reboot.
2: Documents stored on public access computers.
3: Medical terminals used for X-ray viewing.
4: Cash register terminals for storing CC data.
5: CCTV DVRs. If a video time frame needs flagged for long term copying, it is.
6: Proxy/sendmail log servers where logs don't have to be kept for longer than it takes to check if there is an intrusion.
7: Temporary scratch space for a database server, say to pack and unpack normally encrypted BLOB/CLOB data.
8: A special hard disk just for
9: Temporary scratch space when unarchiving data and putting it on a secure partition or tape drive. For example, getting data from tape or another site, storing it temporarly to get a machine to restore locally.
10: A machine set up and automatically imaged for guests to browse the Web.
11: A machine set up and autoimaged in a student computer lab. This way, a power cycle ensures that private data is not recoverable from the previous student.
12: Drives set up for swap. This way, a power cycle removes all traces of a virtual machine's paging.
13: Community clouds, where a VM is cloned to the drive, used to give better capacity, then shut down and the drive cycled so the next user on that drive doesn't have access to the previous user's data.
14: A place to decode encryption keys temporarly pulled out of a HSM to be copied to another source.
15: Airport X-day machines so the private pictures of people stay private.
Flash shared objects is the main thing. Easy fix -- download and use the BetterPrivacy extension.
Of course, the absolute sure way to ensure browser privacy is to have a virtual machine dedicated to browsing, and have it roll back to the last snapshot once done. This is easy to do in Windows 7 and XP Mode. This way, some cookies left behind by some third party add-on (Java, Flash, or W/E) are eradicated completely.