On 2012-12-28 08:45, Jeffrey Walton wrote:
> 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.
Jeff,
I'm not sure how to interpret your comments. Is killing <keygen> a problem
in your eyes? <keygen> is already dead, no mobile bank apps use it which
also means (indirectly) that they don't use "KeyChain" since "KeyChain"
doesn't offer (as of 4.2) a public API for generating keys.
GlobalPlatform SCPnn offers end-to-end-scurity w r t provisioning, <keygen>
does not, neither does "KeyChain". GlobalPlatform is the core ingredient
of EMV cards.
>
> 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.
The problem with waiting for "Perfection" is that you typically get - Nothing.
A good (thought-through) architecture allows features to be added without
disrupting the already deployed ones.
Now, regarding loading an untrusted image this is quite interesting because
a usable system should also support that without exposing trusted images
to vulnerabilities. This can IMO only be addressed at the CPU-level
since only the CPU can know what it booted.
>
> 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.
MSFT and RIM have absolutely nothing for on-line banking.
>
> TLDR: KeyChains are good and their use should be encouraged. Folks who
> own the platform do what they want.
It seems that you believe I'm on a quest destroying Android by putting
keys in files residing in app-space? That must be the TLDR-effect :-)
Anders
>
> 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.
