I'm not an expert an ARM TrustZone, but my understanding is that the fTPM would go there. The idea is that the fTPM has to be protected from an untrusted kernel, just as a hardware TPM would be. There may also be the practical matter that the fTPM has to be available during boot, before the kernel is up, to extend measurements or perhaps unseal a secret key.
Can you be more specific? What issues do you expect?
Does this really cause "Authentication fails" (the subject of the thread)? Or is this a new issue? Assuming it's a new issue, RSA_generate_key() is deprecated, meaning that it's not recommended for new code. However, it's acceptable for existing code. I think the fix is to either use the supplied makefile, which does not have -Wdeprecated-declarations. accept the warning port to RSA_generate_key_ex() I would use (1).
1 - Please send me the complete sequence, starting with a new TPM (delete the old state). It's hard to guess at the problem from just one step. 2 - A guess is that you didn't supply the correct password for the parent of the key you're trying to create. 3- Please email me a complete TPM trace. Generally, the TPM trace will explain the problem. firstname.lastname@example.org
Is this a realistic attack model? You have another process that is running with the same permissions? You decide to use a RAM based file for public key storage rather than just using stack or heap? Again, I think if this is your attack model, you have bigger issues. The process can delete every file on your disk, attach a debugger and read your secrets, kill your process and replace it with its own, etc.
Is it fair to say that, if a rogue process can overwrite your RAM, you have bigger problems? E.g., what would happen if the rogue intercepted your process after the signature verification and changed the return code from failure to success. Or patches your code to skip the signature verification entirely. I think you have to start with your attack model. If it's "the attacker can modify my stack, heap, or program while it's running", I think replacing a key in the TPM is a small problem.
Not in practice. There are two possibilities: 1 - With a resource manager, the RM handles the swapping, and ensures that each process has access to its keys and not those of another process. Another application could load a key, but the RM would swap it out and load your application's key when you wanted to use yours. In fact, typically, the RM swaps out all keys (and sessions) as soon as it loads them, and swaps them back in on demand when they are needed by their application. Swapping (context...
Results: The author confirmed that the book suggestion is an error. The TPM architect for that section stated that it was for efficiency of NV storage. Storing a key with the private part essentially empty would consume a lot of NV space. The TPM reference implementation uses fixed, and therefore maximum size, structures to avoid mallocs, and memory leaks, and to permit static analysis tools to calculate the maximum stack size. The solution, as I suggested, is to store the public part in NV and transfer...