IssueTracker

This issue does not reproduce with dev preview 4.

Closing this issue as per comment #2 from reporter.

Well... then vote for and promote this issue...

I think it could be done using the Linux kernel (dm-crypt/LUKS) for the encryption and then do it like this:
--- On boot mount ---
On the SD-card a special file will be created which is the encrypted "container", this file is used as a device for the kernel module.
Upon boot (after entering the PIN code but before starting other apps) Android mounts first to /sdcard.tmp and should check if there exists this special file and then prompts the user to enter the passphrase. Then it tries to mount the the file from /sdcard.tmp to /sdcard.

--- Encryption setup ---
To setup encryption the user should be able to turn it on in the security settings with a warning notice, that the sdcard will be wiped and that the user should backup all data on it first.
After confirming Android deletes all content and creates a file that takes up all the space on it, which then will be setup as a cryptographic container with LUKS. I think AES 128 bit should be good enough to stop nearly all attackers (unless your name is James Blonde... or sth like that).
--- What needs to be done?
1. Some people who write the interface code for the Android UI - should be fairly easy,
2. Include dm-crypt and LUKS in the kernel used by Android - should be no real problem to port this stuff, hence it's all open source and portable to different hardware platforms.

--- Final words ---
Pro:
1. To read the contents of the SDcard without the phone, all one has to do is:
  a) use Linux or
  b) use FreeOTFE (Windows) to mount the device
2. dm-crypt is included in the linux kernel, LUKS is free software
3. AES is free, fast and secure
4. it does not interfere with any App or the system itself
Con:
1. it might eat a lot of CPU and therefore might be a bit slower, but hence SD cards usually ain't THAT fast (or the Apps that write data to it would NEED the full I/O speed of the SDcard) it's no big deal.

My company (30,000+ employees) will not support Android phones until SD encryption is available.  I'd imagine many others are on the same boat.  If Google wants to continue to make inroads in the corporate environment, this should be a high priority.

My company(6000+) also does not support Android phones because of the lack of SD encryption. IMO it is absolutely crucial that it be added soon. I cant justify getting an Android phone until I can use it for work.

Quite seriously, encryption is really not so much an "option" as a "requirement" for more and more people. This is not only for the SD card but, for some, the onboard storage as well. iPhones and iPads are making inroads into corporates as they tick (not as well as they could) the encryption box. Other areas of concern are provisioning and management but that belongs in another thread.

I need to stick with my trusty fully featured corporate ready Nokia until Android is able to meet this requirement. Even my old Windows Mobile 6 Dopod supported transparent encryption.

In order for any IT department to consider this phone for company use, fundamental security has to be addressed. Standard security features such as encryption, wipe data on password failures, remote wipe of data should already be included. We shouldn't have to find workarounds or pay for apps that give us these features. This phone will not be consider in any government or enterprise private sector until these issues are addressed. And that's a shame because these are two of your biggest markets. We need to get our heads out the sand an enhance the security of the device. I'm using a next generation phone with legacy security features. I'm force to use other devices until for work and my Evo for personal use. Which the EVO is more than capable of handling both. Please for all your corporate users add these features or will be forced to use M$ devices or for god sakes a crackberry.

Our IT dept will not allow this phone to access email until this has been implemented. Please place this as a High Priority issue.

This is crucial for any Business-cases my company considers - please add!

This is mis-filed as an enhancement.  It is clearly a defect.  Google claims full EAS support but does not correctly deliver it.  That is a defect.

Furthermore, the deliberate attempts to thwart security provisions (search on  "lying" and "lies" in issue 36917804) are known as computer crime.  That behavior is a level above a defect and should have been stamped, "Do not ship this product."  A review of change control is needed at HTC and probably at Google.

The millions of employees mentioned in the 8686 issue would seem to qualify for a high priority.

Seriously, this is one crucial and glaring issue that's stopping android from being embraced by the business industry. My company over a 100,000 has accepted blackberry and even iphone for office email, but won't let us use android.

To be honest, I myself do not feel safe about the data I stored on my phone.

Please please please get atleast a security container like true crypt onto this platform where we can encrypt complete SD card, and make it safer for businesses to adopt to this.

Straight question: Why is this topic that is related to security and privacy given a "medium" priority?

Agreed. All personal data is encrypted, bank accounts, credit card information, heck I even have ALL my personal PC's with FULL hard drive encryption. An OPTION for full data encryption is a MUST! But I stress option, I realize battery drain, and performance will take a hit, but for security, some people would use it, others wouldn't. I don't believe implementation would be a huge obstacle. No?

Surely encryption at a volume level will only protect against a lost or stolen phone (sdcard).  A rogue app will still have access to the entire SDcard.
Or have I missed something?

Matt, are you saying all hope is lost?  Surely encryption at ANY level is better than the status quo, rogue apps be damned.  We have to rely on the Android market for protection against malicious apps, but should also expect a reasonable level of protection against the phone (and sdcard) falling into the wrong hands.

I am with Bhave. Some security is better than no security. And if the user uses a good token/password it would be hard for rogue apps to crack it, than have everything laid visible so even a layman can view.

This solution solves the problem being presented by the original poster but not the problems presented by almost anyone else on this bug.  Encrypting the SD Card is not helpful in securing corporate emails, sms, or contacts.  It is also of limited utility for securing the information on the SD card where the phone presents a mass storage capability (as all android phones do).

  If you want the card to be readable on the phone and as a mass storage device then you would be better off storing crypt volumes on the SD card than encrypting the card itself. Given the mass storage presentation of SD cards on android SD card encryption is an empty gesture unless the device itself is also password protected.  

The level that needs encryption support are the databases (where most sensitive information is held) not the SD card. Issue 36904539 is the better starting point if you want encryption at a level suitable for the enterprise requirements that require encryption of corporate data.

Very essential function missing.. hope it gets implemented soon.

With the result of People v. Diaz in the CA Supreme Court, this issue becomes highly relevant.

http://arstechnica.com/gadgets/guides/2011/01/why-you-should-always-encrypt-your-smartphone.ars

FTA:

"Last week, California's Supreme Court reached a controversial 5-2 decision in People v. Diaz (PDF), holding that police officers may lawfully search mobile phones found on arrested individuals' persons without first obtaining a search warrant. The court reasoned that mobile phones, like cigarette packs and wallets, fall under the search incident to arrest exception to the Fourth Amendment to the Constitution."

Sounds like a good as time as ever for encryption on Android.

I agree with several posts here.   Implement dm-crypt in the kernel, already.  At least give the market an opportunity to integrate it at the product level.  

Ultimately, this MUST be possible to apply to every bit of personal data stored on the phone.

Its foolish to think android will make very effective inroads in the corporate world without it

+1 here. If you want Android to be taken seriously by enterprise customers their data needs to be safe.

I'm interested to see how the fingerprint security is executed on the Motorola Atrix. I hope it's not just a different interface to the standard phone screen lock.

I think that full sd card encryption is absolutely necessary. It can be a huge security risk having the sd card unencrypted.

On behalf of everyone who gets emailed when you guys post comments, we appreciate the thoughts, but commentary that can be represented by simply starring the topic should be expressed by simply starring the topic.  Thanks.

For those of you who need access to encrypted data from your mobile should probably be using SSH or HTTPS to transfer it and then delete any sensitive data after you're done with it.

Does everyone who whines about excessive, redundant e-mails have a disk quota or something?  Why not just read the comment and move on?  Why does ANYONE feel the need to whine about such a trivial thing?  Grow up.

Hexsmith: exactly HOW does SSH or HTTPS do ANYTHING to help me protect my contact list if my phone were to be lost, for example?  All of my contacts are stored on the sdcard.  Why?  Why not at least store them on the phone? I'm not aware of any setting that would help guard against disclosure in the event the phone fell into a stranger's (or police officer's) hands?  Where are the inherent protections for the data that is ALREADY ON the phone?

"To show your interest in seeing a particular issue resolved, you should star the issue. Please do not add comments that say simply "+1" or "me too". The comments of an issue should be helpful to the developer who is working to solve the issue, or to other users who may need to work around it. Every comment entered triggers a notification email to other users, so low-value comments only serve to annoy and distract them."

from http://code.google.com/p/support/wiki/IssueTracker

Nice weekend.

@#26: The contacts are not stored on the SDcard, they are stored in the internal SQLite database, unless you used a backup-utility to store them on the SDcard - but this is a little useless if you use a Google-Account for your contacts, because this gets synced automatically. It's, however, important to use the DB in a secure way: Encrypting it with a key derived from the SIM for example, so that the attacker would need your PIN for the SIM to decrypt this data. But this can't protect you if someone gets your phone turned on... the normal screen lock is way too easy to break, so a "Ask for PIN to unlock" option (of course with the ability to use the general PIN or an own just for unlock) would be more secure. This way the attacker couldn't (easily) steal data from the internal memory. Combined with transparent SDcard-Encryption this would be a really secure way.

Concerning rogue Apps: There should be the ability to deny access to certain data for Apps even if they claim to "need access".
Or something like UAC in Windows Vista: If an App tries to access certain data for the first time there could be a dialog asking the user to give/reject permission.

I guess even more could be done to make Android as secure as possible, but that would render the platform unusable, take a lot of time, CPU power & thus battery... not so nice. But it's no reason to not make it available.

The user should be enabled to decide which security level is needed.

loyukfai:

The developers should view the recurrent "+1" or "me too" comments by customers as an opportunity to improve the instructions on the site.  Sarcasm and condescension serve only to annoy and distract the very people who buy the products that pay your salaries.  Continued sarcasm and condescension will result in customers like me taking my business elsewhere.  When enough of us go away, you'll be out of a job.  Then you'll really be annoyed and distracted.  And I won't lose any sleep over it.


PKus...@googlemail.com:

My mistake, I misspoke.  The mail attachments are being stored on the sdcard in the .Mail folder, which is unprotected.

@comment 28 above:

Blackberry does not allow access to even contacts when it detects SIM change, and keeps prompting for phone wipe again and again. I don't think this kind of check would take too much CPU or battery.

This really is a serious drawback !!!
The information stored on smart(phones) is to sensitive and there is to much information to be found on the phone to be left in the open.
So we URGENTLY need SD card encryption AND encryption of the phone.
This should be default implemented in the android OS and not by some add-on (which only encrypts the SD card).
If Android wants to compete with IPhone ad WP7, it should have default encryption !!!

Sadly Android can't be used in our corporate environment without data encryption. Thankfully this policy has also excluded the use of iPads, but means that MS are storming ahead as we can use them with all the corporate messaging systems and force encryption of data.

We're now at v2.2 heading for v3.0 and still no encryption. If Android doesn't want to be seen as just a toy for the personal world it must embrace encryption.

This is really an important issue!  With LUKS it would be very easy to build encryption support into android.  Lots of users won't want to type a password every time they boot their phone, but they can just not do so, and luks support won't hurt them.
Lots of users NEED to be able to protect the data on their phone!

Required by my company 18,000 worldwide by April 2011, or email disconnected.

Smart company.
Now that everybody knows Blackberry is colluding with foreign governments and compromising their users' privacy, it'd be nice for Android to step up and be the new secure option.

While we're waiting for this, if your company uses Exchange, you may use TouchDown which has its own security features including encryption...

http://www.nitrodesk.com/security.aspx

This must be done! It should be open source too so that we can know it will be secure as possible and there are no potential for back doors.

Encryption's purpose is to minimize information disclosure. It can possibly reduce potential for back doors, but that is not its intention nor expectation.

To be honest, the only intelligent solution for encryption would involve hardware. Like a secured external hard drive, there should be an intermediary piece of hardware between the storage medium and the user environment, and multiple keys should be involved that ties the encryption to the device, the OS, and the user, with recovery.

It would be silly to require extra software (ie: Truecrypt for device encryption or LUKS for profile encryption) for the user to manage. Adding complexity would open the feature up to being ignored/not used, leaving the data insecure. Using hardware to manage encryption with the device being the entry point to unlocking the storage would potentially make it be like using it now, which is to make it relatively easy to use.

The one issue is the fact the card would not be accessible outside of the device. Lets be honest, how often are you removing the card? Do you really want it accessible outside of the device? We're talking about securing the data on the device and the card, wouldn't extra-device access essentially be taking a step away from this? If you want security, strive for the whole package, don't pick and choose what suits you.

As for user information on internal storage, it would be difficult to secure it without imposing an excessive performance hit so it would be better to lock down the data separate from the operating system. However, the same hardware can be used for accelerating any encryption being used for things like SQLiteCrypt and whatnot to reduce CPU overhead and reduce the performance hit, and in turn, reduce the impact on the battery.

Unfortunately, for a solution like this, we would likely have to look forward to this in an "Android 2.4" (handset), "3.1" (tablet), or "4.0" (convergence) with specific hardware requirements that add the need for encryption hardware in the hardware profile.

Regardless of what is done, Android needs encryption. I've starred this and many other encryption oriented issues to show my support for this. Without it, Android is a personal and hobbyist platform only, and should be avoided at all cost in the enterprise. Personally, I would like it for my own personal data security.

I'd like to correct some misconceptions you have.  First of all if android is encrypted it *will* be LUKS, even for system encryption, not truecrypt (truecrypt only offers system encryption for windows).  LUKS is the standard for encrypted volumes on linux.  Support for it can be built into the kernel, and it can easily be packaged with a distribution of android, so that it will make you set a password out-of-the-box and work without hassle.

As for processing power, on many phones the performance hit will be noticeable, but it isn't actually that big a deal.  Many phones would still be able to read from their nand flash at full speed without maxing out the CPU.

I appreciate the suggestion that phones should come with dedicated crypto hardware, that would definitely be cool, but don't count out bringing LUKS full system encryption to existing handsets.

I would like to point back to my third party software argument and add to it. There are enterprise environments where software installed on company computers is controlled. As an example, I am not able to use TrueCrypt, FreeOTFE, or other free/opensource encryption systems on my work computer, as the software management only allows the company approved enterprise encryption to be used.

Using LUKS does not remove the requirement for third party software to access the storage in non-Linux environments. It'll work great on the Android system itself, but you still have to consider that in the enterprise most workstations are going to be Windows.

So you're trying to say that LUKS can't solve the problem because of the need for third party software to read the SD card using a card reader.

Well: As long as the SD card is mounted you just can plug in the phone itself and allow the usage as memory. This way the encryption/decryption could take place on the phone and any OS would just use it as a regular USB storage device without noticing that encryption is used.

If your company security policy prohibits the use of simple USB sticks... then I guess you also can't use memory card readers aswell.

Of course we can try to find a solution that will give us everything, make coffee, wash our dishes, buy our groceries... etc. but I think that it's just trying to overthink everything.

Why not start with a small, cheap, fast and secure solution like LUKS and then think about further improvements?
It's better than no system-level encryption functionality at all.

I'm guessing you don't understand how the card is mounted to a connected computer in Android. The card is dismounted from Android and mounted on the connecting computer. In essence, yes, I am loading the card from a card reader, but I never physically remove it from the device. The behavior you are suggesting is what would be required of Android to use something like LUKS, but it is not the current behavior, and the current behavior is likely to not change. Android would be exposing a LUKS encrypted volume to the connected computer, not the data contained therein.

My company does not prohibit the use of USB "sticks" nor card readers. They are allowed as long as encryption is in use. Additionally, USB "sticks" aren't the only USB storage mediums, and neither are card readers. Through our company purchasing site we have access to encrypted hard drives for purchase, which are 2.5" external USB connected hard drives (500gb, etc). Be careful with assumptions.

I'm not saying LUKS can't be used, but that it's not the right solution given the current design of Android. There would need to be fundamental changes to Android to make something like LUKS or any other OS level encryption. I'm assuming the parts that would need redesign will not change in my suggestion for a solution.

Nim, currently in android, when you mount usb storage the fat32 *volume* is unmounted from android and relayed to the host computer.
In a scenario where the sdcard is encrypted with LUKS, the linux operating system sees the luks volume, which it has mounted, to create another virtual volume, which contains the plaintext fat32 volume that it *also* mounts.
If android is running with an encrypted SD card, it can simply unmount the fat32 volume, but leave the LUKS volume mounted, and provide the plaintext fat32 filesystem to the usb-connected computer.  This should pose no problems and your computer won't even know your phone is encrypted.

If you really must be able to take the sd card out of your phone and mount it on your computer, then you will simply has to face the fact that there are NO standards for encrypted removable media that windows supports out of the box, and the third party solutions are largely closed source and you won't see them being used on android.  I'm sorry that your enterprise environment has to try to reconcile windows and security.  Hopefully mounting usb storage on android itself while the phone is running will be enough.

Another thing to consider, if the device has an SD that's easily removable,
Android will need to account for this. In my experience with LUKS it's
easier to corrupt the drive, add in the fact that users typically power down
or simply pull the battery more often on their phones than their computers
there could be some support issues.

I'm all for encrypted SD cards and LUKS is likely the answer but it's not as
simple as turning it on.

To be fair, your sd card will *already* get corrupted if the user pulls the battery.  Fat is a shitty (non-journaling, to be technical) filesystem.

I'd suggest that the sdcard should be formatted ext4, but the windows users will get on my case again...

Encrytion is critical

When are we going to be able to use TrreCryp on Android ?

SD encryption is a must-have!

Atleast make some version of true crypt available to make up for the lack of native encryption.

Android 3.0 allready supports encryption out of the box ;-)

In Android 3.0, developers of device administration applications can support new types of policies, including policies for encrypted storage, password expiration, password history, and password complex characters required.

http://developer.android.com/sdk/android-3.0-highlights.html#enterprise

I think after the 2.3 / 3.0 merge this feature should be available for everyone...

SD encrytion is a must-have

SD encryption is needed to make Android legitimate-- without this basic functionality it seems more like a amateurish OS vs. a serious contender to unseat BlackBerry.  Surprised they don't have this -- I would pay for it.

I'd rather not have it.  If it does get implemented, please make it optional.  

encryption = performance hit...

and...  Are you crazy?  ext4?  Maybe you better take a look at the user base before you make ridiculous suggestions like that.

Obviously all of this would be optional.  Don't come try to block this sort of progress because you personally won't use it.

Android already *has* ext4 support, and allowing it to mount microsd cards formatted with ext4 takes nothing more than changing a mount script.  It would have no effect whatsoever on users who still have their flash drives fat-formatted.

Optimal, of course!
but it's a MUST HAVE thinking that a smartphone is a good tool to use
for business as I've been using my old Symbian.
Yeah, it affects their performance. It not affect very much, though.
The case is: People who use a smartphone for business almost aways have
password, files and contacts inside the phone... if someone stole its
smartphone.. what could be happen? Is better to have a cryptography
system to stay safe :)
We had  a good software for crypt called True Crypt.. It's pretty good
to use in computers and laptops... how about Android Team talk to them
an get together to implement it on Android? :)

i'm sure businesses have concerns over keeping confidential info
confidential my concerns don't stem from business purposes however. my
concerns stem from being able to prevent those in positions of authority
(such as law enforcement officers) from deleting/removing evidence of their
wrongdoings. Being unable to encrypt the sd card allows any representative
of the judicial system to remove the sd card from the phone, browse the
contents and delete anything they feel does not promote a "positive image".

*Quis custodiet ipsos custodes?*
     for centuries, people in positions of power have enjoyed abusing that
power w/ little to no repercussion for their actions. with the proliferation
of video and audio recording cell phones, it is now possible for those who
have been the receivers of such abuses to "level the playing field", so to
speak. to shed light upon that which has prospered under the cover of
darkness. however, as it stands now, those same Abusers can abuse their
position by confiscating your phone under the guise of whatever weak excuse
they can fabricate at the moment and delete pictures/video/audio that could
be used as evidence against them, by removing the sd card from your phone
and plugging it into another sd card reader.

being able to encrypt the entire sd card will deny them this ability.

@chasbig .. Not really since encryption doesn't prevent them from employing their own one-way hash function on the SD card or your phone (smashing it to little bits). For this, we need dropbox, live stream recording, etc.

Julian, I think chasbig's point is still reasonable.  While they can always destroy your phone and data, It's a lot less subtle than if they just delete that one video of them feeding your friend a truncheon.  If every encrypted phone user starts going home after overnight lockup with a wiped SD card, that will *also* be bad press for police.

This should be totally doable using components from OpenSSL or even GnuTLS there should not be any reason for anything violating GPL either.  I am not sure why there is this chat about headers either ( I agree with Linus on "sounding bogus" ).

perhaps someone should implement something for testing using the NDK and then publish results back to Google for implimentation up stream.

Nige

Shut up!! This isn't a message board!

@baropho
your outburst of rage was most unwarranted and most inappropriate, and so
far is the only post that has been off-topic to the discussion about this
issue.

you, yourself, may not see this as a "message board", but glancing through
other issues posted on this bug tracker, it appears many others do not share
your sentiments, as there is much discussion taking place regarding other
issues. all i can say is that if you do not wish to receive replies to this
issue's thread, then please, by all means disable notifications sent to you
by this issue. otherwise, please try to limit your comments to the topic at
hand.

to everyone else, i apologize for the second off-topic post.

Be quiet.

share

this

you

at

@chasebig: thanks for ur subtle way of handling him

@all others who do NOT want encryption: This topic has been created wanting encryption as optional. Let us please work towards it. If u do not want it, just disable the feature... its that simple! Lack of encryption is one reason why android is not being accepted by many businesses. Use truecrypt if u r unsure how it works. It is purely optional and can be used only by those who want it.

BTW, Moxie @ WhisperCore has a beta app for Nexus that does full SD encryption. Anxiously waiting for a general release to test.

@Alex... deleting a file does nothing but unlink it from the file system. Data is still there and recoverable if you're mindful of the situation. Being that a beat cop probably doesn't have the means nor time to securely wipe it for you, his most convenient and plausible deniable method is still the one-way hash method.

Some of us have chosen to receive an email whenever an issue is updated, and that's because we may contribute some *useful* information to help resolve the issue, and/or would like to get updated on the *actual* development. However, hearing your rant is not high on the list.

Thanks for yous subtle way of annoying me, I'm unstarring the issue.

Encryption, please add it soon! I'd just add that when comes to security, Android can be improved in so many ways.
:-(

Here is a proprietary solution. Not the XDA folks "strategy" but for those looking for Corporate Android secured phones it can be a solution. http://mobiwire.com/wp-content/uploads/2011/02/SDROID.pdf
(I am not working for this company, don't ask me for details, in fact I am waiting for information from them)

I think that android should look at using dm_crypt which is included in the
linux kernel.

Comment #68 on issue 36921311 by gautier....@gmail.com: Android too insecure -
Encryption of the SDcard is crucial


http://code.google.com/p/android/issues/detail?id=11211
Here is a proprietary solution. Not the XDA folks "strategy" but for those
looking for Corporate Android secured phones it can be a solution.
http://mobiwire.com/wp-content/uploads/2011/02/SDROID.pdf
(I am not working for this company, don't ask me for details, in fact I am
waiting for information from them)

Encryption is supposed to be in Honeycomb for tables and will thus presumably be coming to future merged phone + tablet versions of Android.

http://www.google.co.uk/search?q=android+honeycomb+encryption

So, unless there's something wrong with the way it works in Honeycomb, it doesn't seem like we need to discuss ideas on how it could be implemented. It's already been implemented and we're just waiting for Google to get Honeycomb (or its successor) into a state fit for phones.

I, among many other users are very interested in a strong cryptographic feature for Android. Full device encryption, not just the SD card, is crucial to protect privacy and prevent law enforcement entities from exercising warrantless searches of cellphones (already happening in California and Michigan, see http://arstechnica.com/tech-policy/news/2011/04/michigan-state-police-we-only-grab-your-cellphone-data-with-a-warrant.ars for an example).

Currently the only solution I've found is WhisperCore, which is an actual ROM replacement.

Useless link, offtopic.

Full device encryption is crucial!

I need to encryption on my Android.  My company refuses to offer them to its employees unless they have encryption.

Full device encryption is absolutely essential.  To protect local user data and cloud data both from thieves and the prying eyes of overzealous law enforcement agencies.

Not too sure if this has been posted before:
http://www.whispersys.com/whispercore.html and https://github.com/WhisperSystems/WhisperYAFFS/wiki

Hoping something like this gets implemented.

@77: Yes, comment 71 mentioned WhisperCore.

Dear people,

Posting comments on the bug report is for people with development concerns.

We have seen enough "android needs encryption because of X".

Posting "libcrypt-foo would be perfect"... don't want to hear it. Seen it a
lot.

Starring an issue means you want to know when something happens. I have seen
an awful lot of nothing happening here.

If you are considering posting anything other than "I have implemented it,
patch here..." then may you please consider drinking Draino instead.

Funny nothing has been posted since Dan's comment.  Must be a dead issue.  Too bad.

Should be top priority after all these recent security breaches. I'm still amazed this isn't taken more seriously until it hits the media.

[Comment deleted]

#81

if you are concerned with google leakiness simply use android phone WITHOUT adding gmail credentials. Power android calendar with hotmail ActiveSync.  IMAP4 free from yahoo, fastmail, all paid email.  Applications actual freeware from fdroid or purchase applications directly from developers.  Consider using (a fork of) CyanogenMod.  

Google's "free" services have a high privacy breach COST.

#83 - This topic is about encrypting the SD-Card. GMail credentials are another issue. If someone gets physical access to my phone (forgot it somewhere, was stolen, etc) it does not matter if I locked my phone with a passcode or what cloud service providers I've chosen. The SD-Card can still contain a lot of information that could be gathered simply by removing it and placing it in another device.

Personally, I assumed the breeches #81 was referencing were related to the phone itself, and not "google leakiness". (ex: http://www.securelist.com/en/analysis/204792176/IT_Threat_Evolution_for_Q1_2011). This issue is most certainly related to the phone itself.

Truecrypt quality full disk encryption.  Take whatever steps feasible to minimize or eliminate the risks of unencrypted code remaining in garbage collection regions and other issues discussed on the Truecrypt forum and elsewhere for solid state memory.

I would also like to see an OPTION to encrypt the SD card from within Android. The thing is that it needs to be portable. For instance, if your device dies for whatever reason and you need to access data on the SD card, you should be able to insert it into another device and provide the key to decrypt. The other reason to make it purely optional is to mitigate any hinderances to performance.

The Linux kernel already supports dm_crypt. Someone could implement a
frontend for it if it is present in the Android kernel.

I don't care if it is portable or not, I make a simple sync backup every few weeks. What is really important for me is that if the phone is robed they won't have access to 16 GB of my data on the SD card including some very personal stuff.

Truecrypt or equivalent for the entire SD card is mandatory for people in the Finance industry. If Google wants to appeal to a multi billion dollar industry they had better get this completed yesterday. A password to mount the SD card must also be secure.

SD card encryption is a must have for any business owner. please implement this as soon as possible. Thank you

I read that honeycomb has full encryption. That would mean it will be in the next major version of Android that merges honeycomb into the phone branch.

Yes. My tablet (Galaxy Tab 10.1) has that feature... But, it doesn't have SD or MiniSD. It only encrypts the whole tablet internal memory. Not sure if there is going to be an option for SD. Hope google does it.

I really need a ecrypted sd card as soon as possible. Anyone in the business world really.

Just to add my 2¢. We really need (at least) sdcard encryption and preferrably also encryption of the internal memory for official FW. The kernel supports it so add this and welcome a lot of business users.

I agree with @92. I have a ASUS eee pad transformer, it has two external SD cards, one micro and one standard. I would not like the device to encrypt my SD cards "on-the-fly" if I put a card in the slot. Example would be if I want to use the SD card to transfer photos from my camera and then put it back in the camera.

The Samsung I9100 Galaxy S II, running Android 2.3.3, has full device encryption, including external SD card encryption (but only if it is a policy on the exchange server, you cannot manually encrypt the device)

Putting a SD card in the phone will encrypt the card without asking you, and your card is unusable in any other device.
(did that misstake when trying to transfer movies from my Asus to my Samsung, couldn't use the SD card in the Asus anymore after that, needed to format the card)

SD card encryption needed to comply with security standards, but also an option to decrypt the SD card for safe removal, and an option to not encrypt temporary SD cards, like external card readers, or attached USB sticks for that matter.

Completlt Agree with this

This thing is completely doable. Android uses device mapper for its A2SD. All we need is the cryptsetup command ported & shipped with devices (and a pretty upgrade for those of us who have already bought an Android). That shouldn't take too much work. Why hasn't it been done yet? If none of the devs/manufacturers cares for security, I will attempt to cross-compile cryptsetup myself. I consider the"medium" priority to be a very, very, very sad thing.

I agree with Dragonia that medium is a sad priority.

Dragonia - I am willing to help in any way I can.  I am not very Linux savvy (been probably 15-20 years since I managed a nix box), but I am knowledgable about cryptography and have extensive network security experience in the Windows realm.  Let me know if I can be of any help if you attack this yourself.  I think it would be awesome if the community offered a good encryption solution for Android, since Google is prioritizing other features first.

@previous comment: Thank you for your support! I will not get to this sooner than next week, but if and when I manage this I will definitely post. Like I said, all the necessary tools except for cryptsetup are already available in stock Android phones, so it is a (relatively) simple matter of cross-compiling one command (and possibly some libs, although most of them should be available on Android too). Therefore I think I should manage it in a couple days. Hopefully we will have encryption soon =)

@last three comments : not so fast. Don't want to ruin your morale, but it's gonna be hairy (think small clear-text startup system to boot the device and ask for the key, with processes to be reattached or something when you've decrypted and mounted the main storage, etc...). 'Been thinking about it for some weeks and it's gonna be quite a challenge, I think !
At least if you want FDE. I'd suggest keeping it simple and beginning with only external-sdcard encryption, or with a loop if you don't have external sd, then aiming for the whole thing.

You may be interested in this : https://github.com/guardianproject/luks/wiki (scroll down to the 'references' part)

Also, we'll most probably have FDE with ICS, which will be out in october/november (hoping google won't wait for too long before releasing source code...)

I was about to get my hopes up, until Dragonia posted "simple matter" and "a couple days". (sigh) Right. So no encryption anytime soon.

LUKS definitely makes it sound more complex than I thought it would be too.  One thing I think that is important to distinguish at least in these community-driven efforts is the scope of the encryption.  I would be happy if just the sdcard were encrypted since it's so easy to pop out and avoid a remote wipe.  That would be miles ahead of what we have now.  Getting the internal user data and/or system data encrypted is just icing on the cake.  Eventually I would like to see full device encryption, but until then, I at least want my poor sdcard encrypted!  

On device boot password I think is also a must-have feature.  Without a TPM, I don't trust on-device keys.

Will it be possible something imilar to U3 sistem used on flash drive? I need to read and syncronize with my desktop after decrypt.

According to:
Comment 928 of Issue 36910061:
"Marking this released. Between Android 2.2 and 3.0 most of the policies initially referenced in this issue were added. Per stadler's comments, please create new issues for policies which are still missing, so we can rank the specific policies by demand."

According to http://en.wikipedia.org/wiki/Comparison_of_Exchange_ActiveSync_Clients (which, according to comment 931 of that issue, represents an accurate list of supported policies) ICS does not have SD card encryption (it does have full disk encryption).

While this issue is a mess, it is close enough to the required feature. Once the ability to encrypt the SD card is in there, it would be trivial to support the ActiveSync provisioning policy that requires it. This is necessary for a large number of enterprise customers to adopt Android without third-party solutions like TouchDown. It is also necessary in order for me to feel comfortable about all the information that I have to put on the SD card because I'm constantly hitting space constraints.

Presumably the same technology that is used for the internal encryption could be extended to the SD card. It would be excellent to see this happen.

I came across the details of the internal Android encryption here:
http://source.android.com/tech/encryption/android_crypto_implementation.html

I have owned an Android phone for nearly 2 years now. I knew there was no on device encryption with the Eclair 2.1 firmware on my Samsung Galaxy S but was confident with the might of google that an update would soon resolve this. Come on!! 2 years and still no on device encryption support. In a day and age where identity theft is rampant and mobile phones contain so much more than just telephone numbers this it is unnacceptable for me that a firm that pushes smartphones ignores the basic safety needs of it's users. (Many of whom probably don't understand the significance of not having this feature). Sort it out google.

Examining the specification for SD cards at www.sdcard.org I found out that there is an optional feature for sd cards, mentioned in this document: https://www.sdcard.org/downloads/pls/simplified_specs/Part_1_Physical_Layer_Simplified_Specification_Ver_3.01_Final_100518.pdf, that enables a low level (hardware) Password Protection using sort of a command (CMD42 LOCK/UNLOCK); So I contacted the association about the availability of such a software and though they replied they are "not involved in the development of SD products or software" they confirmed that "the software certainly could be developed."

So that is a high-Priority feature addition to the android family!

Does this mean there's work on this?

@Android team Guys, can we have an ETA, or atleast a possible intent that whether it would be addressed in the any of the upcoming releases?

[Comment deleted]

The only answer I've found to see if the  SD card is encrypted or not is to use the mount command and search for /mnt/sdcard-ext. Here is a sample of a cmd class I created/plagiarized off the internet :) to allow you to use the native linux commands on Android:
class CMDExecute {

          public synchronized String run(String[] cmd, String workdirectory)
              throws IOException {
            String result = "";

            try {
              ProcessBuilder builder = new ProcessBuilder(cmd);
              // set working directory
              if (workdirectory != null)
                builder.directory(new File(workdirectory));
              builder.redirectErrorStream(true);
              Process process = builder.start();
              InputStream in = process.getInputStream();
              byte[] re = new byte[1024];
              while (in.read(re) != -1) {
                System.out.println(new String(re));
                result = result + new String(re);
              }
              in.close();

            } catch (Exception ex) {
              ex.printStackTrace();
            }
            return result;
          }}

I then call this function which calls the CMDExecute class above passing along any standard linux command in the kernel, so grep does not work since it's an add on binary:
public static String fetch_disk_info() {
            String result = null;
            CMDExecute cmdexe = new CMDExecute();
            try {
              String[] args = { "/system/bin/mount" };
              result = cmdexe.run(args, "/system/bin/");
            } catch (IOException ex) {
              ex.printStackTrace();
            }
            return result;
          }

You can search on the returned string which is the output of mount as you would expect it on any *nix os. As I stated above you would look for /mnt/sdcard-ext and see if the file system is vfat or encryptfs. I have a screen print of the mount command after I cut out all the other mount points to show only the sd card.

[Comment deleted]

[Comment deleted]

[Comment deleted]