On 2012-12-30 05:18, Jeffrey Walton wrote: > On Sat, Dec 29, 2012 at 10:58 PM, Jeffrey Walton <[email protected]> wrote: >> On Fri, Dec 28, 2012 at 12:16 PM, Anders Rundgren >> <[email protected]> wrote: >>> On 2012-12-28 11:22, Jeffrey Walton wrote: >>> <snip> >>>> ... >>>> On the device: why not use BouncyCastle to generate keys (after >>>> getting a user seed), and then store the secrets in the KeyStore >>>> (pre-Android 4.0) or KeyChain (Android 4.0+)? >>> >>> AFAIK, "KeyChain" doesn't offer a public interface except P12 >>> import which is only suitable for "experiments" and then there >>> is the moderately useful <keygen>. >> Sorry to resurrect here :) Forgive me if you already know this. >> >> Believe it or not, you have everything you need. Here's how I would >> use a KeyChain that *only* allows PKCS #12. No passwords, and no blobs >> (symmetric keys) - only PKCS #12. It's a 'minimum' implementation that >> defers to the operating system. >> >> If you want to analyze security levels of the system as data flows >> though entities, it ultimately relies upon pin/password/passphrase >> strength. That's because we lack a second factor. >> >> ... >> As the data value or sensitivity level increases, you have to increase >> the length of the password. At some point, you hit a limit on >> usability and have to switch to a second factor.
It is quite possible that we approach this issue from rather different angles. The uselessness of the second factor depends on the robustness of the key access-control mechanism. If you have the option to perform any number of tries you need a long and awkward second factor. In *my* world there are different kinds of attacks where some are hard-to-impossible to address. However, these attacks are based on physical access to the device/token. And even here there are distinct levels: - "Using" the key - "Stealing" the key without the owner's knowledge Anyway, one of my core points is that the Google Wallet uses much better technology including secure key-storage than Google offers for third-party applications like mobile banking. Personally I find the Internet-based credit-card payment systems as defined by the payment giants, VISA and MasterCard, pretty broken both from a usability and security-point of view. Since these systems still depend on information printed on the card *surface* (including the CCV "password"), it seems that this sector could use some new stuff. It is pretty obvious that Google is the best candidate to make this happen. The banks will eventually retire the EMV-card since they never got it to work on the Internet! Regards Anders >> >> Second factors are not an end-all. They are broken too in financial >> systems. Confer: "Two-channel breached: a milestone in threat >> evaluation, and a floor on monetary value", >> http://financialcryptography.com/mt/archives/001349.html. > Forgot to mention..... > > Its not just "phones as second factors" that have problems (residual > risk). Hardware tokens have problems too (residual risk). See Dr. Matt > Green's "A bad couple of years for the cryptographic token industry," > http://blog.cryptographyengineering.com/2012/06/bad-couple-of-years-for-cryptographic.html. > > RSA's SecurID's have been analyzed, and an attacker only needs to see > two consecutive pins (IIRC): "Cryptanalysis of the Alleged SecurID > Hash Function (extended version)," eprint.iacr.org/2003/162.pdf. > > Someone else's "second factor" means you confer trust (think: all the > problems with PKI and Public CA Hierarchy). Can you really trust RSA > Data Security in a security context? Remember, RSA Data Security lied > and covered up when faced with a breach that compromised those keys. > When caught, RSA called it an "APT," when all it really was a > successful phishing attack. > > 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.
