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. > > Best Regards, > Zoltan > > > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/android-security-discuss/-/6poe9eu6CZsJ. > 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. > > > > -- > create interesting things. > > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/android-security-discuss/-/HNmwxyWFCzoJ. > > 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. > > > > -- > create interesting things. -- 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.
