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. ***** If your sensitive data its a password, then: * generate random DES3 or AES key * encrypt password under DES3 or AES key * encrypt DES3 or AES key with PKCS #12 public key If your sensitive data its a file, then: * generate random DES3 or AES key * encrypt file under DES3 or AES key * encrypt DES3 or AES key with PKCS #12 public key Now this can surely be improved. Let's assume the threat model includes copy/paste attacks across devices. You would use the following: * generate random DES3 or AES key * fetch non-malleable device information * transform device information * derive key (from random key and transformed device information) * encrypt password under derived key * encrypt DES3 or AES key with PKCS #12 public key Transform device information means you don't directly use the UUID or MAC address (or whatever else you come up with). I would recommend an HMAC since it [provably] acts like a PRF, and the inner ppad (ipad) and outer pad (opad) provide protection against some length extension attacks that may or may not apply. ***** 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. 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. But they greatly improve assurances, which greatly minimizes loss potential. 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.
