On Mar 4, 2015 5:15 PM, "Shawn Willden" <[email protected]> wrote: > > Typically, (though this is implementation-dependent)
What is the intent of that documentation? Would an implementation that releases the key bytes in a plaintext fashion in any way satisfy that as long as the on disk storage is encrypted for that device? the TEE implementation wraps the key bytes with a symmetric key which is never available outside of the TEE and returns the result to userspace for storage. To the keystore daemon, specifically. Some TEE implementations may instead have their own segment of flash which is marked as secure and therefore unavailable to the regular OS, and store the key bytes there, returning a handle to keystore. I'm not aware of any that do that, but I don't know much about the details of how the various implementations work. > > On Wed, Mar 4, 2015 at 5:41 PM William Roberts <[email protected]> wrote: >> >> Can you clear up the text on isBoundKeyAlgorithm(String algorithm) >> >> Returns true if the current device's KeyChain binds any PrivateKey of the given algorithm to the device once imported or generated. This can be used to tell if there is special hardware support that can be used to bind keys to the device in a way that makes it non-exportable. >> >> Does this mean that the key bytes themselves (whether in memory or disk) are never to be returned outside of the privileged implementation (think tee or txe), or that the blob as stored on disk cant be copied from the orignating device to another device? >> >> On Wed, Mar 4, 2015 at 1:51 PM, Shawn Willden <[email protected]> wrote: >>> >>> TZ implementations can and should make use of HW RNGs, though the existing ones are closed source and I can't say what they actually do. >>> >>> On Wed, Mar 4, 2015 at 11:41 AM William Roberts < [email protected]> wrote: >>>> >>>> Ok, so just another sanity check. Is the TZ implementation purely software based, or does it make use of any rng's or anything like that for seeding the keygeneration, etc. >>>> >>>> On Tue, Mar 3, 2015 at 7:35 PM, Shawn Willden <[email protected]> wrote: >>>>> >>>>> "Hardware-backed" means "in ARM TrustZone" on all existing devices. Since TrustZone isn't separate hardware but a secure mode of the main CPU, key generation should be almost exactly as fast as a software key, since the only additional cost is the context switches in and out of secure mode. If KeyChain.isAlgorithmSupported returns true for an algorithm, that means that algorithm is supported in secure hardware (actually, TrustZone) on your device. >>>>> >>>>> On Nexus 5, keystore.msm8974.so is the HAL module that talks to the Qualcomm trusted OS. >>>>> >>>>> On Tue, Mar 3, 2015 at 8:25 PM William Roberts < [email protected]> wrote: >>>>>> >>>>>> Without rooting an image, is there a way to test if AKS is hardware backed? KeyChain.isKeyAlgorithmSupported("RSA")) returns true, but others suspect the generation times are too fast (1.2-1.7 seconds). >>>>>> >>>>>> On Kitkat Nexus 5, I see /system/lib/hw contains 2 keymaster implementations: >>>>>> >>>>>> keystore.default.so >>>>>> keystore.msm8974.so >>>>>> >>>>>> I initially was going to look at the memmap of keystored to see what was loaded. Any comments, much appreciated. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> Visit this group at http://groups.google.com/group/android-security-discuss. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> >>>> >>>> -- >>>> Respectfully, >>>> >>>> William C Roberts >>>> >> >> >> >> -- >> Respectfully, >> >> William C Roberts >> -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/d/optout.
