I would have to agree with John. Better if Android avoid the mistakes of the PC industry and design with support for h/w security from the get go. The PC industry has spent over a decade (since 1999) working on the TPM hardware, and now it is in most of PCs (commodity). Still has some issues. Similarly the card industry spent years developing SmartCards, and now it is in all USIM cards in GSM phones in Europe and Asia (and soon US).
Many Enterprises do wish to allow employees to connect their mobiles into the corp network and directory services. However, the lack of "security" in many mobiles has put off many orgs. Do we know if Apple has plans to use TPM/smartcards in future iPhones? /thomas/ On Aug 13, 8:47 pm, "John Markey" <[email protected]> wrote: > in truth > > there is no security without hw enforcement (like wintel), so it becomes when > does Android have securiity and can be trusted with valuable info > if we agree cloakware-like is not going to be strong enough... and the open > model is too risky > > at present to make apps run and have people have fun with new apps, with a > vail of trust, hope you can trust the source of the app > > lets protect: > personal info (killer App #1 for security) > financial info, no one will put banking info on Android if they have $$$, or > will do special bank account with no money < 1k$, other... > DRM... (dead by now) > > Corp IP (email, ... worth much more), if an IP company (like .... > can't allow an Android phone mobile device if no real security, hw enforced > > is there a process to address this in Android, otherwise it is fun but not... > > imho > john > security arch. > > ________________________________ > From: [email protected] > [mailto:[email protected]] On Behalf Of Dianne > Hackborn > Sent: Thursday, August 13, 2009 4:53 PM > To: [email protected] > Subject: [android-security-discuss] Re: Do they need to change the security > keys for the OEM? > > 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]<mailto:[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]<mailto:[email protected]>> wrote: > Require? I think that is unlikely. > > On Thu, Aug 13, 2009 at 9:55 AM, John Markey > <[email protected]<mailto:[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]<mailto:[email protected]> > > ________________________________ > From: > [email protected]<mailto:android-security-disc...@g > ooglegroups.com> > [mailto:[email protected]<mailto:android-security-d > [email protected]>] On Behalf Of Dianne Hackborn > Sent: Tuesday, August 11, 2009 6:44 PM > To: > [email protected]<mailto:android-security-disc...@g > ooglegroups.com> > 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]<mailto:[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]<mailto:[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 > <caoht.cn<http://caoht.cn>@gmail.com<http://gmail.com>> 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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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.
