<div dir="ltr">Agreed. I can't speak for the gentleman that originated this thread but in my context the use case would be to store the keys/certs within the TPM that's all. <div><br></div><div>Regards,</div><div>Freemon</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 7, 2017 at 12:03 PM, Blumenthal, Uri - 0553 - MITLL <span dir="ltr"><<a href="mailto:uri@ll.mit.edu" target="_blank">uri@ll.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And in most cases (except those involving TPM-based platform attestation, which I don’t think has anything to do with OpenSSL use cases),  a separate hardware token (like a smartcard, or an HSM) would IMHO be a much better and more usable choice. PKCS#11 engine (libp11) to access those is quite popular and work well.<br>
<br>
--<br>
Regards,<br>
Uri Blumenthal<br>
<div class="HOEnZb"><div class="h5"><br>
On 7/7/17, 11:53, "openssl-users on behalf of Michael Wojcik" <<a href="mailto:openssl-users-bounces@openssl.org">openssl-users-bounces@<wbr>openssl.org</a> on behalf of <a href="mailto:Michael.Wojcik@microfocus.com">Michael.Wojcik@microfocus.com</a>> wrote:<br>
<br>
    > agreed, but this engine  does not really put the keys inside the TPM - instead it sets up a local repository that is encrypted<br>
    > using a key from the TPM. If you look at the way it is designed, it is not really secure (as it's not impossible to find the<br>
    > password that was used to encrypt the keys with).<br>
<br>
    "really secure" is not a useful phrase. Security is a set of asymptotic trade-offs between attacker and defender work-factors under a threat model. Nothing ever achieves "really secure".<br>
<br>
    Even a hypothetical OpenSSL engine that performed all cryptographic operations on the TPM wouldn't achieve specified security under the TPM threat model unless the engine, all of OpenSSL, and whatever is invoking it were part of the TCB.<br>
<br>
    That said, there is certainly a case to be made that an OpenSSL engine which performed at least some crypto operations on the TPM is of at least academic interest. Someone might want to start with the Trousers engine and try extending it. (Enhancing an existing engine generally isn't particularly difficult, in my experience, though of course it depends on what you're trying to do and what APIs are available.) Or try writing a fresh TPM engine using, say, the Windows TPM API.<br>
<br>
    It might help to know what your use case is.<br>
<br>
    Michael Wojcik<br>
    Distinguished Engineer, Micro Focus<br>
<br>
<br>
    --<br>
    openssl-users mailing list<br>
    To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><br>
<br>
</div></div><br>--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><br>
<br></blockquote></div><br></div>