On Fri, Dec 28, 2012 at 4:09 AM, Anders Rundgren <[email protected]> wrote: > 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. > > 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. Oh, not at all. I didn't even make a comment on that.
I don't care one way or the other as long as the key is 2048 or 3072 bits. You can use OpenSSL if you'd like, for that matter. > 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. Yep. 2nd factor is a good thing. Its a shame every device does not have a fingerprint reader. > 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. It does not matter to me how you do it as long as you don't lose the data. Here's Microsoft's architecture for Windows Phone: http://channel9.msdn.com/Events/TechEd/Europe/2012/WPH304 No second factor, but no DFU/Recover Mode games either. >> 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. For whom? The consumer or the enterprise? For the consumer, its generally low-value data and banking apps are fine (some risk is accepted). On the other end of the spectrum, "Board Pad" apps gave me the most trouble. I declined every one that passed by my desk. There was no way to allow Mergers & Acquisitions, Salary, Pending Litigation, etc on an iPad with no passcode or a PIN (no risk accepted). The potential for financial and reputational loss was too great. In between were the sales apps. They could be hit or miss, but we can generally work with them once the risks are known, controls are placed, and the residual risk accepted. >> 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 :-) Not at all. I suspect you have more abilities than the average user/developer. The average developers has to follow the rules so he/she does not make the same mistakes his/her predecessors made. The rule: defer to the Operating System. 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.
