Ataes 132 a KeyTransfer

Log in or register to post comments
Go To Last Post
4 posts / 0 new
Author
Message
triggerinput
triggerinput's picture
Level: New Member
Joined: Fri. Aug 2, 2019
Posts: 2 View posts
#1
Posted by triggerinput: Wed. Aug 14, 2019 - 03:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have problems running the Legacy Command with the Volatile Key. I have a working SPI Communication with an ATAES132a. I can read, write the memory and run all kinds of commands. Now I tried to accomplish a simple KeyTransfer to the Volatile Key (0xFF).

I configured the UserZone 0x00 s.t. the VolatileTransferOK flag is True and AuthRead, AuthWrite, EncRead and EncWrite is false. Than I performed the following steps:

 

1. Write Key and VolUsage to User Memory at address (0x00, 0x00)
0x02                            # SPI: Write data to memory (Table 20-2)
0x00                            # UserMemory address upper byte (I use the first 32 Byte of UserMemory)
0x00                            # UserMemory address lower byte
0x03, ..., 0xf7             # 16 Bytes Key
0x40, 0x00, ..., 0x00 # 16 Bytes (First two bytes VolUsage) 0x40 => LegacyOK = True (VolatileKey Configuration) (Table 4-3)

 

2. Read Status Register until only RDY Flag is True

 

3. Read 32 Bytes at address (0x00, 0x00) to confirm that everything was written correctly.

 

4. Key Transfer Command
0x02    # SPI: Write data to memory (Table 20-2)
0xFE    # Lower
0x00    # Upper
0x1A    # Opcode KeyTransfer Command
0x00    # Mode always 0x00
0x00    # Always 0x00
0xFF    # Key Volatile ID
0x00    # Lower Byte Adress User Memory
0x00    # Upper Byte Adress User Memory
0xB5    # CRC 0
0x84    # CRC 1

 

The KeyTransfer Command returns 0x00 as Return Code, means it is successfull
0x04  # Length

0x00  # Return Code

0x98 0x03 # CRC

 

Unfortunately a Legacy Encryption with Key ID 0xFF returns 0x80 as return code, which means KeyErr. If I perform the same chain of commands using KeyID 0x01 everything performs as expected and the ciphertext is returned. I assume that there is a problem while transferring the VolUsage part because 0x40 should allow me to use the VolatileKey with the Legacy Command.

 

Does anybody know which little flag or configuration I am missing?

Tags:

Security, General Security Discussions
Top
PhillyNJ
PhillyNJ's picture
Level: Resident
Joined: Sat. Oct 11, 2014
Posts: 707 View posts
Posted by PhillyNJ: Thu. Aug 15, 2019 - 01:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

triggerinput wrote:
Does anybody know which little flag or configuration I am missing?

 

The devil is in the details with the ATAES132a. I put together an all-in-one demo here a few months ago including a volatile key load example. I wrote the demo because I would forget everything after I moved on.

 

The demo is for i2c version, but could be configured over SPI. I might have those SPI files somewhere (message me). There is also a walk through on my github page on how the demo is configured. There are a bunch of real-time examples.

 

Message me if you need help. I haven't touched the AES132a in a while and I will have to review my notes. The AES132a was a beast to tame.

 

 

 

 

 

 

"When all else fails, read the directions"

Top
triggerinput
triggerinput's picture
Level: New Member
Joined: Fri. Aug 2, 2019
Posts: 2 View posts
Posted by triggerinput: Mon. Aug 19, 2019 - 06:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you PhillyNJ for trying to help out and sharing your demo code. I looked into it but did not find the KeyTransfer Command used anywhere (maybe I am blind...).

 

However, I was able to fix the problem by switching the VolUsage Bytes. But this bothers me. In the specification (Table 4-3) as in your tutorial pdf (Page 16) the following is defined for VolUsage:

Reserved            0 7
LegacyOK           0 6
AuthCompute     0 5
RandomNonce  0 4
DecryptOK          0 3
EncryptOK          0 2:1
AuthOK               0 0
Reserved           1 7:2

DecRead            1 1
WriteCompute   1 0

 

Based on this I was setting the two Bytes to 0x4000 as written in 1. of my original question, but it only works, when I switch these bytes and send 0x0040 instead. Am I missing some byte endian stuff? I was banking on the sentences:

" - All arrays are transmitted in index order, with byte index 0 first.
 - Configuration fields that are more than eight bits appear on the bus during a Read or Write in the index order in which they appear in this specification. The top byte in the input parameters table is byte<0> and appears first on the bus. These fields are arrays of bytes, not multi-byte integers." (1.2.1, Documentation)

 

Top
PhillyNJ
PhillyNJ's picture
Level: Resident
Joined: Sat. Oct 11, 2014
Posts: 707 View posts
Posted by PhillyNJ: Mon. Aug 19, 2019 - 10:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

triggerinput wrote:
Based on this I was setting the two Bytes to 0x4000 as written in 1. of my original question, but it only works, when I switch these bytes and send 0x0040 instead.

 

Yes this is very confusing but its how the bytes are loaded when configured. It is like this on the ATASHA204a and ATECC508a too. I made the mistake of loading some configurations backwards like you and locked the chips. Ugh!

 

I have created some code for the ATASHA204a and ATECC508a provisioning and print out the configuration to the terminal. I verify the configurations by printing the configuration table and by checking it against a spread sheet. I still need to do this for the ATAES132a but its pretty simple to implement.

 

This is an example for the SHA204a:

 

"When all else fails, read the directions"

Top