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. >
