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.
