Note: Chrome-on-ChromeOS already supports software-backed keys by placing them in the 'public' slot (which is tied to the NSS profile in the user's homedir), rather than the 'private' slot. Options such as Import vs Import & Bind used to/still allow the distinction between where to import.

Similarly, Chaps supports 'software-backed' keys when the TPM itself doesn't support the algorithm (e.g. TPMv1.2 vs TPM 2.0 support). In this model, Chaps protects the keys with a TPM-backed key and manages access.

Using Chaps as the backend for these keys is preferable over using the NSS public slot, as this ensures that Chaps-using applications (such as wpa_supplicant or ARC++) would potentially have access to these keys without introducing additional NSS dependencies.

I'd add that even for supported algorithms, chaps only will create a tpm-backed key if 

(a) a special attribute (kKeyBlobAttribute = CKA_VENDOR_DEFINED + 1) is set for an imported key [see SessionImpl::CreateObjectInternal in platform2/chaps/session_impl.cc]. 
Note how we pass this attribute it for the keys registered by cryptohomed/atetstationd as a part of attestation workflows - e.g. Pkcs11KeyStore::Register in 
platform2/attestation/server/pkcs11_key_store.cc

(b) this key was generated by chaps itself [then this attribute will be auto-set by chaps - see SessionImpl::GenerateKeyPair in platform2/chaps/session_impl.cc].

If those keys are generated externally and then imported, it seems we just need to avoid passing this special attribute. So, this feature request may be not for chaps, but for other layers and workflows that use it.

* oops, a better code reference for #7:
(a) a special attribute (kKeyBlobAttribute = CKA_VENDOR_DEFINED + 1) is set for an imported key [see SessionImpl::WrapPrivateKey in platform2/chaps/session_impl.cc]. 

Assigning to atwilson@ for CrOS triage.

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

Assigning to Pavol since he expressed an interest - let's discuss next-steps when he's back in the office.

Menghuan is this related to / could be incorporated into the work you're doing in chaps?

Issue 855675 has been merged into this issue.

Note comment #7: we may not need any changes in chaps.

I spend sometimes for tracing the code. Correct me if I am wrong.

As my understanding, the work depends on the use case.

The current status is that for the importing the a private key through C_CreateObject, it will be wrapped by TPM at SessionImpl::WrapPrivateKey if it is a permanent object (a.k.a token object in PKCS#11). The object type can be decided by caller via setting CKA_TOKEN attribute to true/false.

So if caller want to use software-backed key, they can only import the RSA key as temporarily object (a.k.a session object) for now. I am not sure whether it is enough for your use case. If not, then addition work is need.

a) if caller want to use software-backed key for permanent object. We can add a customized attribute to tell chaps that we don't want to wrapped it by TPM to bypass the WrapPrivateKey.

b) if caller want to create a software-backed key by chaps itself (call GenerateKeyPair), then we need to add the other customized attribute to focus it software-backed gen. 

Any information about what's our requirement/use case here?

Note this was filed as an umbrella bug; see the related bugs. I'd missed that one had been (incorrectly) duped into this.

It sounds like Comment #19 is discussing the use case from Issue 855675 - is that correct? Perhaps we should pop over there?

The desire is for a permanent object, software-backed, without the additional TPM invocation overhead. This can be approximated by using the Cryptohome-protected NSS softoken database (as mentioned in Comment #1), but that has some of the limitations that it would not be available for those other services.

This would not guarantee full TPM security, but would substantially improve performance over, say, Issue 851113, for organizations that are willing to make that trade-off.