I would imagine that it would be supported at some point, but there is no schedule at this point.
On Thu, Aug 13, 2009 at 3:28 PM, Hadi Nahari <[email protected]> wrote: > OK, if not require, then will the usage of HW security be supported? > > -Hadi > > > On Thu, Aug 13, 2009 at 2:29 PM, Dianne Hackborn <[email protected]>wrote: > >> Require? I think that is unlikely. >> >> >> On Thu, Aug 13, 2009 at 9:55 AM, John Markey <[email protected]>wrote: >> >>> All >>> >>> asked this some time ago and it may not be changing >>> >>> will future versions of Android require hardware features for support of >>> security: >>> >>> Trustzone like secure virtualization of the processor execution >>> environment >>> OTP internal data storage for one time programmable keys or identity >>> Crypto Acceleration (AES, SHA, RSA, ECC,...) >>> >>> is this planned or discussed for future versions >>> >>> >>> thank you >>> john >>> security architect mobile devices >>> broadcom >>> [email protected] >>> >>> ------------------------------ >>> *From:* [email protected] [mailto: >>> [email protected]] *On Behalf Of *Dianne >>> Hackborn >>> *Sent:* Tuesday, August 11, 2009 6:44 PM >>> *To:* [email protected] >>> *Subject:* [android-security-discuss] Re: Do they need to change the >>> security keys for the OEM? >>> >>> There are no guarantees about how secure a device is without ro.secure >>> being set -- at this point only devices with it set have been shipped, so >>> there hasn't been a security review for the system running without it set. >>> I doubt any one person actually knows what all is impacted by not having it >>> set. >>> >>> As far as carriers, the big one is giving the user root access. Sure, if >>> you have ro.secure not yet, then the user can get root access... but >>> because this configuration hasn't been productized, there are some >>> potentially disturbing repercussions such as the fact that all you need to >>> do is leave adb access on, and anyone can plug your phone into a computer >>> and have root. If a non-developer phone is going to ship without ro.secure >>> set, at the very least I think it would be required to have a facility to >>> set a root password. >>> >>> Bottom line: if you are going to ship a device without ro.secure set, be >>> sure to examine all of the code that this impacts to make sure you are okay >>> with the result. >>> >>> On Tue, Aug 11, 2009 at 6:02 PM, Disconnect <[email protected]>wrote: >>> >>>> Doesn't the setting of ro.secure depend on his needs? (At least, the >>>> engineers on IRC are always claiming that the "proper" android setting is >>>> off and it is the evil carriers who insist on turning it on, etc.) Turning >>>> it on may be the right answer but it doesn't seem like it is the only one. >>>> >>>> >>>> On Tue, Aug 11, 2009 at 8:30 PM, Dianne Hackborn >>>> <[email protected]>wrote: >>>> >>>>> When you are creating the user image for your device, you need to sign >>>>> everything with your own private keys that nobody else has access to. You >>>>> also need to make sure the ro.secure system property is set, and that the >>>>> build phase for generating the final dexopt files into the system image is >>>>> done (so dexopt doesn't need to be run at boot). >>>>> >>>>> This is the "mydevice-user" configuration. Generally development will >>>>> happen with "mydevice-eng" or "mydevice-userdebug", but the result of >>>>> these >>>>> build configurations is not intended for shipping on a device. >>>>> >>>>> >>>>> On Tue, Aug 11, 2009 at 5:21 AM, cht <[email protected]> wrote: >>>>> >>>>>> >>>>>> The security keys under the directory android\build\target\product >>>>>> \security is used to sign the apk for defferent security level. do >>>>>> they need to generate some new keys of theirself or do not change it >>>>>> for some compatible problems? >>>>>> >>>>>> thank you >>>>>> >>>>>> cht >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Dianne Hackborn >>>>> Android framework engineer >>>>> [email protected] >>>>> >>>>> Note: please don't send private questions to me, as I don't have time >>>>> to provide private support, and so won't reply to such e-mails. All such >>>>> questions should be posted on public forums, where I and others can see >>>>> and >>>>> answer them. >>>>> >>>>> >>>> >>> >>> >>> -- >>> Dianne Hackborn >>> Android framework engineer >>> [email protected] >>> >>> Note: please don't send private questions to me, as I don't have time to >>> provide private support, and so won't reply to such e-mails. All such >>> questions should be posted on public forums, where I and others can see and >>> answer them. >>> >>> >> >> >> -- >> Dianne Hackborn >> Android framework engineer >> [email protected] >> >> Note: please don't send private questions to me, as I don't have time to >> provide private support, and so won't reply to such e-mails. All such >> questions should be posted on public forums, where I and others can see and >> answer them. >> > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
