Hi, Please find my answers inline.
BR, vivek. On Dec 10, 12:32 am, Kipling Inscore <[email protected]> wrote: > On Thu, Dec 9, 2010 at 03:07, Vivek Madathil <[email protected]> wrote: > > I am exploring a way to support SD card encryption on android. We > > need to support only file content level & file name level (not > > partition level) encryption. > > [...] > > 1) Will integrating the proprietary security algorithms at bionic libc > > APIs that provide file access routines (fread, fwrite ) a good > > option ?. We know that there will be a performance drawback due to > > this. > > Good option by what metric? > Performance? Android policies and common practices? Strength of > security? Flexibility? Purpleness? > Vivek> We are looking at a design approach that is compliant to android & linux kernel (GPL) licensing. Performance and strength of security are also critical factors for deciding security mechanism. > Some questions that might help guide us to the best approach: > What is your goal? What are the criteria for your encryption system to > be successful? > Why do you want to encrypt (who are you protecting the data from, who > are you limiting it to)? > Who is your target audience (general public, internal to your > organization, regulation compliance, ...)? > Which android version/platform do you want to be able to deploy this > on (any, newer than x, versions, custom build that you have control > over)? Vivek> We have to support SD encryption compliant to Exchange Active Sync (EAS) "<RequireStorageCardEncryption>" in android froyo based release. The implementation shall use 3rd party FIPS 140-2 certified algorithms. This is a custom build we have control over. > Integrating your proprietary security algorithms into bionic libc will > only work on Android devices that include this modified bionic libc, > and it seems that if you only use the libc/stdio APIs it will only > support a single encryption key/scheme. There might be some resistance > to a closed-source version of bionic libc, so it might not get wide > support outside of your own build. Is there a reason you want to > integrate with bionic libc? Have you considered and rejected other > options? Vivek> I have evaluated LUKS/ecryptFS as two options. However, they are implementations at kernel level. At present these file systems are using their own implementations of cryptographic libraries. We want to use 3rd party cryptographic libraries that are FIPS certified for the final solution. Since integrating 3rd party cryptographic libraries under GPL will be an issue, I am looking at other alternatives (that does not violate any licensing terms) and considered integration of the cryptographic libraries at bionic (BSD license). As I said, this is a custom build we have control over and the android devices can use the the modified bionic libc. We don't want to change the standard read/write APIs and want to ensure that any content written using these APIs get encrypted. I understand your point on single encryption scheme. We need to support only AES128 encryption algorithm. Performance goals: Read/Write performance times to SD card with encryption/decryption has to be at least 80% to 90% of the Read/write performance times without encryption. Performance will be measured in miliseconds. > What sort of performance drawback are you concerned about integrating > with bionic? > What are your performance goals? > > I would suggest that if you only wish to encrypt the names and > contents of a few files in one application, or you wish to make this > work on version of Android that you don't control/build, include the > encryption mechanisms with the application. Use standard file access > methods, but decrypt after reading and encrypt before writing. If you > need to integrate non-Java code use the NDK. Vivek> After SD encryption is enabled by exchange admin, content written to SD card from all applications shall be encrypted. With the above approach, we will have to modify many applications. If you have any other suggestions, let me know. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
