Add support for writing to and reading from a slot #6
Conversation
AndrzejKurek
force-pushed
the
read_write_slot
branch
3 times, most recently
from
650ab67 to
277586a
Compare
| @@ -34,4 +34,14 @@ psa_status_t atecc608a_init(); | |||
|
|
|||
| psa_status_t atecc608a_deinit(); | |||
|
|
|||
| /** Read from a given slot at an offset. Data zone has to be locked for this | |||
| * function to work. */ | |||
| psa_status_t atecc608a_read(uint16_t slot, size_t offset, uint8_t *data, size_t length); | |||
There was a problem hiding this comment.
Why would the driver expose a way to read/write at an offset? The API only provides a way to import/export the key as a whole.
There was a problem hiding this comment.
There is a possibility to store arbitrary data at any slot (slot 8 in our case), for example a certificate, or a signature. The user might want to write and/or read to a slot, depending on the configuration.
There was a problem hiding this comment.
Ok, but that would be exposed through the API via psa_import_key and psa_export_key with the key type PSA_KEY_TYPE_RAW_DATA. These functions read/write the whole slot.
There was a problem hiding this comment.
Ok, I didn't know that that's the plan. I can refactor the import_key and export_key procedures to factor for that, I would just like to get a confirmation from @Patater.
There was a problem hiding this comment.
Sounds like we don't need extra function pointers in the struct then, since we have import and export function pointers already. Let's use those.
Do we want to register a new driver struct under a different lifetime for handling raw data? or add a switch statement inside the existing driver import/export function implementation?
There was a problem hiding this comment.
The export_key function won't know about the key type unless it's passed to it or if it will check the hardware to determine which method of reading to use.
There was a problem hiding this comment.
Oh, you mean the export_key function in the driver? I guess it should receive the key attributes as an argument. Right now it only gets the size and location. Why isn't it enough to know the size and location, by the way?
There was a problem hiding this comment.
The public key is stored fragmented and padded, and has to be read using a dedicated atcab_get_pubkey function that converts it to a readable format. Clear text reads are used for raw data, and exporting a private key is not even possible.
There was a problem hiding this comment.
OK, so the secure element API has to be updated. Should I do it? Will it be a part of a different PR? @Patater - are we planning on switching from https://github.com/Patater/mbed-crypto/tree/secure-element to an official branch?
There was a problem hiding this comment.
There are other pending updates to the SE API to cope with driver registration, key registration and updates to the application API. That's on me at the moment, together with https://jira.arm.com/browse/IOTCRYPT-608 and https://jira.arm.com/browse/IOTCRYPT-778
AndrzejKurek
force-pushed
the
read_write_slot
branch
from
277586a to
634c41f
Compare
There was a problem hiding this comment.
I'm happy with the read/write functions as implemented for now. We should register them in the driver struct's import/export, reading/writing the full slot (like a block device), when possible as part of https://github.com/ARMmbed/psa-crypto/issues/202
Example should use atecc608a_read() and atecc608a_write() directly until we have the functions registered with the driver struct.
There was a problem hiding this comment.
Approved. I don't think the API of the functions atecc608a_read and atecc608a_write is useful, but this can be improved later.
Fix the version of driver library
Support added for a clear text read and write. Please review only the two write/read commits.
This is a prerequisite for ARMmbed/mbed-os-example-atecc608a#5.