Not able to generate public key - unknown error

MarceloSalazar commented 4 years ago

I'm able to run the application using GCC (using PR https://github.com/ARMmbed/mbed-os-example-atecc608a/pull/32) but it seems I'm failing to generate a public key on a specific slot.

Sequence:

Generate private key in slot 2

generate_private=2
Generating a private key in slot 2... Done.

Generate public key in slot 3 using slot from private key 2

generate_public=2_3
Exporting a public key from private key in slot 2... Done.
Importing public key to slot 3... Failed! Error -134.

Generate public key in slot 2 using slot from private key 3 (should fail and display message)

generate_public=3_2
Exporting a public key from private key in slot 3... Done.
Importing public key to slot 2... Failed! Error -134.

Issue 1: it shouldn't fail in step 2. I might be doing something wrong, but I couldn't figure out from the docs
Issue 2: there should be a better description of the error message for both -140 and -134

@Patater @dgreen-arm @adbridge

MarceloSalazar commented 4 years ago

I reproduce the same problem with RC2, on both AC6 and GCC_ARM

AndrzejKurek commented 4 years ago

I have reproduced it on my configuration too, but it's expected for it - what configuration are you using? If key slot 3 is configured to hold a private key (as it is for me) - trying to import a public key into it will fail. You can tell that by analyzing bytes 96-127 of the configuration zone (KeyConfig area - usage permissions and control, two bytes per slot), and for slot 3, it's bytes 102-103 in particular. You can view the current configuration zone with the info command. Here's a decoded version of my configuration of this slot, as a reference:

/* 0x1300 - ‭0001 0011 0000 0000‬

(15-14) 00 X509id - Public key validation by any format signature by parent;

(13) 0 RFU - Must be zero.

(12) 0 IntrusionDisable - Use of key independent of the state of IntrusionLatch.

(11-8) 0000 AuthKey - Zero becaues ReqAuth is zero.

(7) 0 ReqAuth - No prior authorization is required before using the key.

(6) 0 ReqRandom - A random nonce is not required for a specific group of commands.

(5) 0 Lockable - Slot cannot be individually locked using the Lock command.

(4-2) 100 KeyType - P256 NIST ECC key

(1) 1 PubInfo - Public version of a key can always be generated.

(0) 1 Private - Contains a private key */

To see if that's the case, please try to use a public key slot that's configured to hold public keys (for the reference configuration it's slots 9-14).

adbridge commented 4 years ago

@MarceloSalazar ^^

MarceloSalazar commented 4 years ago

@AndrzejKurek note I'm looking at this from the user of the application point of view, so the first point clear to me is that there is something wrong and the output doesn't help. Therefore we needed the example to display a message coherent to the error and provide clarity to the user. For example "Slot for public key is already used by private key", or whatever might be the problem.

Now looking into details... I'm successful at generating a private key at slot 4 but when I try to generate a public key in slot 5 it fails and I don't know why. I'm not using the same slot.

generate_public=4_5
Exporting a public key from private key in slot 4... Done.
Importing public key to slot 5... Failed! Error -134.

But if I try to generate a public key into slot 8, it succeeds:

generate_public=4_8
Exporting a public key from private key in slot 4... Done.
Importing public key to slot 8... Done.

What might be wrong... why one works and the other doesn't?

info

Serial Number:
01 23 BA CF BA D3 29 CA EE

Config zone: 01 23 BA CF 00 00 50 00 BA D3 29 CA EE C0 3D 00
C0 00 55 00 83 20 83 20 83 20 83 20 83 20 83 20
83 20 83 20 00 00 00 00 00 00 00 00 00 00 00 00
00 00 AF 8F FF FF FF FF 00 00 00 00 FF FF FF FF
00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF 00 00 00 00 FF FF 00 00 00 00 00 00
13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00
1C 00 10 00 10 00 10 00 10 00 10 00 10 00 1C 00

--- Device locks information ---
  - Config locked: 1
  - Data locked: 1
  - Slot 0 locked: 0
  - Slot 1 locked: 0
  - Slot 2 locked: 0
  - Slot 3 locked: 0
  - Slot 4 locked: 0
  - Slot 5 locked: 0
  - Slot 6 locked: 0
  - Slot 7 locked: 0
  - Slot 8 locked: 0
  - Slot 9 locked: 0
  - Slot 10 locked: 0
  - Slot 11 locked: 0
  - Slot 12 locked: 0
  - Slot 13 locked: 0
  - Slot 14 locked: 0
  - Slot 15 locked: 0
--------------------------------

It's not clear to me how exactly decode the information. But hold on, if we have an application in place, why don't we make this simple for the user instead of asking them to decode bits? For example:

--- Device locks information ---
  - Slot 0 locked: 0 (private key)
  - Slot 1 locked: 0 (public key)
  - Slot 2 locked: 0 (unused)
...

AndrzejKurek commented 4 years ago

First, to answer your question - for ATECC608A, the hardware slots (described here, page 11) have the following capabilities:

Slots 0 -7 can contain 36 bytes of data, so only private/secret keys, or data;
Slot 8 can contain up to 416 bytes of data, be it private or public keys, signatures, certificates, or just any data;
Slots 9-15 can contain 72 bytes of data - public/private keys, or data.

Hardware slots up to slot 7 cannot contain a public key, that's why your first case fails. The second case succeeds both because physical slot 8 can contain a public key, and because the configuration that's used, and verified by the driver, probably permits that (I can investigate your configuration further tomorrow, but that's not so relevant right now).

Now to your last question - why do we let the application users suffer by telling them to decode bits? That's because of several reasons:

There are many layers at which we can validate what users want to do.

At the "what's permitted by hardware level" - by checking if someone tries to export a public key to slots 0-7, for example. Not sure if any other error checking can be put here.
At the configuration level - by checking if the operations that the user tries to perform are incorrect from the configuration point of view. This can be done, but will not guarantee that the operation will be succesful, because we can't read all the data that's in the hardware. The driver operates on this level, but the errors are often vague and 95% of the time it's ATCA_EXECUTION_ERROR on any failure, which translates to PSA_ERROR_HARDWARE_FAILURE.
At the data level - driver/hardware operates on this level depending on whether the data is secret or not, and again, upon failure, ATCA_EXECUTION_ERROR is usually returned.

As you can see, there are a couple of levels of checks that we could add, but it would require a long time to test, along with provisioning the devices with different configurations and flashing them with various data in slots. It would also increase the codesize greatly (since we double the checks), and the gain would be only better (more readable) errors.

The hardware configuration is very convoluted and intertwined. Certain fields in the config zone have different meanings depending on other fields. These operate in different modes. Sure, we can print out that the public key field is set, but the slot itself can be still unlocked, so unusable. Or a flag can be set so that it can't be used for certain operations. Or a counter, telling how many times it can be used is already maxed. Or this might be a public key, but there's no data. There are really many, many variations.
There's no metadata we receive from the hardware telling us what is already put in a given hardware slot.
So far this example was created to showcase certain features of ATECC608A with a given configuration without being tightly tied to it. Preparing a comprehensive example that would handle all cases would require significantly more work. There was no request for a feature that would parse and pretty print the whole configuration, covering all of the variations. This can be done, but please raise such request to @Patater.

I agree though that, instead of printing -134, the application could print PSA_ERROR_NOT_SUPPORTED. Not sure if it would really help the user though.

MarceloSalazar commented 4 years ago

@AndrzejKurek thanks for the detail information. It really helps!

I understand now the context on which the application runs and the ATECC608A device is restricting a bit the information that can be shown.

I feel we can resolve the issues mainly with documentation updates - IMO this information is highly important that should be brought to the example's markdown doc as it's, as will help most users:

Slots 0 -7 can contain 36 bytes of data, so only private/secret keys, or data;

Slot 8 can contain up to 416 bytes of data, be it private or public keys, signatures, certificates, or just any data;

Slots 9-15 can contain 72 bytes of data - public/private keys, or data.

And some of the information shown in your points (2) (3) and (4). I'll try to raise a PR with a proposal.

I'll let you handle the error code in a different way if you can.

MarceloSalazar commented 4 years ago

See proposal: https://github.com/ARMmbed/mbed-os-example-atecc608a/pull/37