> agreed, but this engine does not really put the keys inside the TPM - > instead it sets up a local repository that is encrypted > 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 > password that was used to encrypt the keys with).
"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". 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. 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. It might help to know what your use case is. Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
