Hi Zoltan, > The TPM low level stuff is the pro way but the more I think the more I'm on > some kind of high level protection. Because in my case the apk is the part > that holds the value and it is signed and compiled in dex. You really need a secure co-processor to do what you want. In its absence, you need to look at how a TPM can be leveraged to achieve your goals. You won't find secure co-processors and TPMs on COTS phones.
> Of course it would be great to build some fully secure platform based on low > level authorisation during boot, but I think based on your description it > needs serious and non-trivial design and extension of the architecture. It already exists - UEFI and Secure Boot (www.uefi.org). Windows Phone 8, Windows 8, Fedora, Ubuntu, and Suse are using it (or have plans to use it). It starts at the SoC and continues into the loaders. Lots of good reading: https://www.google.com/#hl=en&sclient=psy-ab&q=uefi+secure+boot+filetype:pdf. > I think in my case it would be enough to extend this system with some kind > of filesystem encryption to save the valuable apk and its database which is > already encrypted. the other stuff is just texas instruments open source > stuff which could be reproduced easily. Software as a Service (SaaS). Have your program run on a server to protect the IP, and send the results down to the client in a web browser. > what do you think about android gingerbread and ics filesystem encryption, > can I say that I want to encrypt /system/app and /system/data ? The system is only as strong as user passwords. And you don't have control over the password policy. Jeff On Tue, Aug 14, 2012 at 2:43 AM, Zoltan Rak <[email protected]> wrote: > Thanks for the detailed description. Yes I thought it won't be easy, > especially that I'm mostly operating in the higher layers and have only a > few months experience with platform. > > Beaglebone is a great stuff but this "file system plain on sdcard - root > filesystem included" freaks me out. > > The TPM low level stuff is the pro way but the more I think the more I'm on > some kind of high level protection. Because in my case the apk is the part > that holds the value and it is signed and compiled in dex. > > Of course it would be great to build some fully secure platform based on low > level authorisation during boot, but I think based on your description it > needs serious and non-trivial design and extension of the architecture. > > I think in my case it would be enough to extend this system with some kind > of filesystem encryption to save the valuable apk and its database which is > already encrypted. the other stuff is just texas instruments open source > stuff which could be reproduced easily. > > what do you think about android gingerbread and ics filesystem encryption, > can I say that I want to encrypt /system/app and /system/data ? so that if > somebody puts the micro sd in a reader these parts will remain secure and > unreadable? > > BR, > Zoltan Rak > > On Aug 14, 2012, at 2:30 AM, mark gross <[email protected]> wrote: > > FWIW the idea I was noodling with was to have a TPM-like device with an i2c > interface hooked to the device such that if the device is pulled from its > mounting case then the key's needed to unlock the root FS would not be > available. But, there is still lots of room for this to fail. (like the > disk key's will be in the clear in the boot loader or maybe in an untrusted > kernel.) > > Basically to protect a device from a physical attack (where the device is > pulled from its normal housing). i.e. the security is based on the notion > that no one would think of putting a keystore for the FS key over a wire > into a difficult to move docking station type of thing. As I thought of it > I'm pretty sure there are already a dozen variations on this idea. > > Also protecting the key from an i2 bus sniffing attack is a problem. I > guess a SAC could be set up between the key store and the kernel in early > boot. (but as the kernel would be in the clear and missing a useful root of > trust I don't think there is a lot that could be done.) > > I think I can solve most of the issues but, still we have a mostly > untrustable kernel in early boot where the FS key is in the clear and > accessible using a JTAG attack on the bootloader or the kernel. (depending > on choices) > > its a tricky problem. > > --mark > > On Mon, Aug 13, 2012 at 6:19 AM, sodjas <[email protected]> wrote: >> >> Hi Mark! >> >> Sorry for the delayed repsponse :) >> Yes thats exactly the case, I figured out the same... >> But what I exactly want to do is to protect an application developed by us >> compiled into the system as native app. >> I also found that if I set ro.secure=1 then there is only shell user >> access >> I can also disable adbd >> But the painful thing is that the hacker can still pull out the sdcard and >> put it in a card reader and copy the apk. >> I think the only way to protect unauthorized use is to wrap a unique code >> to all apk build in a POJO which will became a dex and id hard to decrypt >> and to have some hardware authentication too like MAC or othe unique stuff - >> which can still be punked with a custom platform that is giving you back a >> fake MAC... >> >> Any ideas or patterns for this kind of security? >> >> 2012. július 17., kedd 20:24:33 UTC+2 időpontban mark gross a következőt >> írta: >>> >>> I've thought about some similar issues a while back but, don't have many >>> ideas. >>> >>> But, you are talking about using one of the standard linux encrypted OS >>> features to protect the root partition. >>> >>> you'll basically need an encrypted FS for your root file system. (easy) >>> >>> getting the crypto keys to the kernel in anything close to a secure >>> manner will be interesting to see done. (hard. You don't have a trusted >>> u-boot.) >>> >>> Further you don't have a trusted kernel. (also hard ) >>> >>> Storing the crypto keys for the file system is also an interesting >>> question. >>> >>> Basically you want to have your encrypted FS not decrypt for anything but >>> a trusted uboot and kernel. I.e. only trusted (as defined by the FS) >>> kernels and maybe boot-loaders should be allowed to decrypt the FS. >>> >>> I'm not sure how such a beast could be created without some sort of >>> trusted execution environment which I don't think exists on the beagle bone. >>> >>> --mark >>> >>> On Tue, Jul 17, 2012 at 6:09 AM, sodjas <[email protected]> wrote: >>>> >>>> Hi Guys! >>>> >>>> I imagine this topic not to be like an exact problem or a question but >>>> have a constructive brain storming and gather ideas how to protect micro SD >>>> based Android installations like ones on Beagleboard and Beaglebone >>>> platform. >>>> >>>> The keywords could be: platform security, integrity check, secure >>>> u-boot. >>>> >>>> The main topics to brainstorm on could be: >>>> 1 How to protect the micro sd so that the Android OS and its root >>>> filesystem can't be fetched with a simple are reader >>>> 2 How to extend or use alternatives for u-boot to check kernel and root >>>> filesystem integrity >>>> 3 Is there an alternative for Beagleboard-like firmwares to store a >>>> compressed/encrpyted instance of firmware instead of having a plain root >>>> filesystem readable by everyone >>>> >>>> Any comments from more experienced fellows are welcome. I'd for this >>>> topic to cover a wide spectrum how to protect your system even if you have >>>> a >>>> micro SD based platform. -- 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.
