Finished object demo. #12
Conversation
| #include "demo_helpers.h" | ||
| #include "pkcs11_demos.h" | ||
|
|
||
| /* RSA private key that has been generated off the device. |
There was a problem hiding this comment.
I'd add some disclaimer like "users are not advised to hardcode keys, put keys in readable memory, ...".
You've made the point that "it's an example" and just for demonstration when "the device itself cannot create credentials". Though, in production, this approach is absolutely not OK in my opinion. And if anything, I'd like to make sure it doesn't come back to us.
FreeRTOS-Plus/Demo/FreeRTOS_Plus_PKCS11_Windows_Simulator/examples/objects.c
Show resolved
Hide resolved
| /* PKCS #11 defines objects as "An item that is stored on a token. May be | ||
| * data, a certificate, or a key." This demo will show how to create objects | ||
| * that are managed by Cryptoki. */ | ||
| prvObjectImporting(); |
There was a problem hiding this comment.
A dump question... why not just call prvObjectImporting() and prvObjectGeneration() at one layer above? Since the two demos seem to be irrelevant to each other.... (Usually with back to back calls, I'm kind of assuming it implies a designed flow. Where as in this case, we can call these two separately or reversed order. )
From my understanding... prvObjectImporting() parses an existing private key, and call C_CreateObject to recreate a key based on the information extracted from the existing key. And prvObjectGeneration() generates key pair. So it sounds like they are two work flows for IoT products.
There was a problem hiding this comment.
Good point, I will update this
There was a problem hiding this comment.
Hmm actually, i'd like to keep it as it is so the demo can scale up if there are more examples to be added for this, for example importing a certificate. This way it keeps the bloat down in the demo header file and main.c
There was a problem hiding this comment.
(I just noticed you commented back, apologies for the delay. 80%+ of my emails go to trash directly... )
Keeping it like this is certainly fine. In the long run, maybe we want to have white paper equivalent sort of things, to call out different workflows with certificates. Or maybe on demo webpage, some wording like -- "if device is capable, we recommend ...". (All good practices could go here. Like don't load keys into memory, use secure element, ...... ) Otherwise, user could generate keys with IoT Core and load private key into memory etc.
You might have already done so in demo page, which I haven't quite read through. This comment is left in ignorance of relevant existing documentation.
|
|
||
| configPRINTF( ( "Creating private key with label: %s \r\n", | ||
| pkcs11configLABEL_DEVICE_PRIVATE_KEY_FOR_TLS ) ); | ||
| configPRINTF( ( "FreeRTOS_P11_Key.dat has been created in the Visual Studio" \ |
There was a problem hiding this comment.
Have we created FreeRTOS_P11_Key.dat until this point?
There was a problem hiding this comment.
Oops, I'll move this printf to after the call to create.
FreeRTOS-Plus/Demo/FreeRTOS_Plus_PKCS11_Windows_Simulator/examples/objects.c
Show resolved
Hide resolved
No description provided.