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<https://groups.google.com/d/msg/android-security-discuss/-/6poe9eu6CZsJ> >>> . >>> To post to this group, send email to android-secu...@**googlegroups.com. >>> >>> To unsubscribe from this group, send email to android-security-discuss+* >>> *[email protected]. >>> For more options, visit this group at http://groups.google.com/** >>> group/android-security-**discuss?hl=en<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.
