On Thu, Dec 9, 2010 at 23:33, 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. On Thu, Dec 9, 2010 at 03:07, Vivek Madathil <[email protected]> wrote: > 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.
Disclaimer: I am not a lawyer, this is not legal advice, you should probably seek advice from a lawyer, etc, etc... but you might want to look into the details of the Linux kernel licensing. If I recall correctly, loadable modules may be closed source. The kernel module interface, however, may change between versions; if you decide to switch from one version of Linux to another, you might have to modify the modules. For strength of security, it's probably best to put this in the kernel, making it more difficult to circumvent by malicious users or malicious applications and unsuspecting users. Compliance with licensing is a little more tricky--you seem to have the basic idea: avoid mixing code that must stay closed with code that must stay open, but you might be able to get better technical results if you get advice from a lawyer on the specifics of how closely you can connect these pieces of code. > 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. In that case I suppose there's no technical issue with modifying the system or adding a layer to the platform. There may also not be a legal issue, even of modifying GPL'd source... You don't have to publish source or publicly offer it if you keep the changes to yourself--thus I think due to corporate personhood or something, it's legal to restrict GPL'd code to within a single organization, though not across organizations through NDAs, etc...but ask a lawyer if you're considering this, since I could be wrong and there might be some complications specific to your situation that I'm not aware of. > 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. Since you want the encryption centrally controlled and performed by all applications, it would make sense for your implementation to be transparent to any uses of file operations, so this should be put at the lowest level of the system that handles file operations independent of file system or perhaps in a file system driver (if you're only using one or a limited number of file systems), but you'll have to investigate the legal issues if you want to do this since it's likely in the kernel, thus GPL. So you might want to find the lowest level userland file operation component that is BSD, public domain, or otherwise open/specified but does not require modified version to be open--hopefully there will only be one of these so you don't have to modify multiple things or worry about some applications side-stepping your encrypted file operation path--this may be bionic libc. If the loadable module path is legally and technically feasible you might look into BSD licensed file system drivers (loadable in Linux or port from e.g. Mach). -- 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.
