ATECC508A can't do privWrite

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, all!

I'm testing ATECC508A using AT88CK590, and I'm trying to write my own private key.

I set slot 0 as follows:

slot_0_config

 

Now, I locked the configuration zone, and now am trying to write to this slot before locking the data zone.

write command doesn';t work, apparently because it's defined as holding ECC key. 

So I tried writing with privWrite:, and it still doesn't work.

the command I used was: 

46 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 

)the key is just 0000....(

This still does not wortk and retrurns 0x0f.

Anybody have any idea why this might not work?

Thanks!

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm recently working on the chip ATECC508A. I've successfully written a private key to the chip (slot 0), using command PrivWrite.

Take those steps bekow:

1. Config the slot 0. We may use the default configuration (as your picture shows, SlotConfig is 83 20, KeyConfig is 33 00).

2. Lock the Config Zone.

3. Use command PrivWrite to write your private key to slot 0 (Data Zone is unlocked). You have to compose the command and send the raw bytes to the chip. The response would be `04 00 03 40` if it succeeds. However, you can not see the content in the slot 0 as it is private.

4. Lock the Data Zone.

 

Now, you can use Sign and Verify commands to test.

 

So back to your problem, you're using PrivWrite command (that's the right way), but the raw bytes format is not right. The whole command is composed of three parts: 1. length (1 byte) 2. packet (72B) 3. CRC16(2B).

The packet part consists of opcode (1 byte), param1 (1B), param2(2B) and data(68B).

If you are using pass-through mode (write private key in clear text), the length should be 75(0x4B), then follows packet part, and finally calculate the CRC16.

 

So, the bytes you offered seem like it's just a packet, have you tried the whole command (with length and CRC16)?