On Fri, Dec 28, 2012 at 1:57 AM, Anders Rundgren
<[email protected]> wrote:
> ....
>
> Proof: The Google Wallet doesn't utilize on "KeyChain"/<keygen>-like
> technology for provisioning,
> it rather builds on (according to unverified sources...) GlobalPlatform's
> SCPnn.
Well, that's a slippery slope. At minimum we need to know the Threat
Model they are using for the system.
On one hand, you can *not* offer KeyChain/DPAPI, in which case you end
up with secrets scattered on the filesystem from the various
applications. That's all an application has, and that's what it has to
use.
On the other hand, if you offer offer KeyChain/DPAPI, then an
application can store secrets in KeyChain/DPAPI and defer security to
the operating system. I prefer this approach because it removes the
onus from the developer.
For Google Wallet, Google is not just "some developer" prone to get
things wrong. It's their platform, and they have intimate knowledge of
the architecture and security controls in place to protect secrets. So
I would be more inclined to trust Google's implementation after a
brief code review (rather than an a typical developer after an
in-depth code review).
The KeyChain/DPAPI and operating system still need help, but you won't
see any advances until you have secure boots and trusted paths.
Otherwise, DFU/Recovery Mode tricks will load an [untrusted] image,
and that will lead to recovery of the secrets. It takes more than just
a TPM or security co-processor.
BlackBerry and Windows {Phone|RT} 8 lead the field in secure boots for
commodity devices. As far as I know, Apple and Android still have
gaps. I could be wrong though - Apple and Android may have added it
recently. Its hard to keep up at times.
TLDR: KeyChains are good and their use should be encouraged. Folks who
own the platform do what they want.
Jeff
--
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.
