How to get Auth and AuthCompute to work? ATAES132A

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

Hi All, 

I ran authCompute cmd but kept getting 0x50 error.   My data sent : 

uint8_t Blk1[] = {
       0x03,0x01,0x00,0x00,0x00,0x07,0x00,0x00,0x00,0x00,0x00
         };
    uint8_t Blk2[] = {
         0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
         };

ret = aes132m_execute(AES132_AUTH_COMPUTE,0b00000000,0,0x0000,11,(uint8_t*)Blk1,16,(uint8_t*)Blk2,0,NULL,0,NULL,(uint8_t*)TxBuff,(uint8_t*)RxBuff);

MacFlag was wrt pg 112

Blk 1 and blk 2 was wrt pg 116

I tried all the modes in blk 1 but still got error 0x50 returned

 

As for Auth, I ran and obtained the outbound Mac, fed it back as an InMac but got Mac error 0x40

I set the nonce inseed with all 0xA5. As its still in testmode, I got all 0xA5 for output random no from Nonce cmd.

I checked to ensure the commands ran right after nonce cmd and even used info cmd to check macCount to verify its 1.

 

Please advise

This topic has a solution.
Last Edited: Thu. Oct 5, 2017 - 08:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You cannot use an outbound MAC as an inbound MAC, and vice-versa. Both the mac_count and the mac_flag will be different for each even if the nonce is the same.

Each MAC calculation is unique - as it's supposed to be.

 

The AuthCompute command (which I didn't use as I calculated/verified any MACs myself, will calculate MACs for you to send to a 2nd synchronised device.

 

According to the datasheet, error code 0x50 is "Bad opcode, bad mode, bad param, invalid length, or other encoding failure".

So it looks like your command format is wrong so the authentication is not even attempted.

 

Last Edited: Tue. Oct 3, 2017 - 02:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi anha6317,

Thanks for your reply.

I cannot figure out what is wrong with the input I've sent to AuthCompute.

Page 34:

Opcode 0x14

Mode 0x00

MacKeyID  0x0000

Zero 0x0000

FirstBlock  0x03 01 0000 0007 00 00000000

SecondBlock 0x00000000000000000000000000000000

 

Could you clue me in?

Thanks

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

You can debug into the aes132m_execute call to see what the command packet the library is building.

 

Then you can also look at the I2C or SPI  bus and see what is actualoly being sent to the chip.

 

What you do know is the chip isn't happy with the command it receives.

 

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

Hi anha6317,

 

Yes, I've done that and verified with the debugger that it is indeed sending out the commands are above.

Could it be one of those errata in datasheet issue you've previously spotted? Seems the previous guy asking you about AuthCompute also has problems with this

 

Thanks

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A couple more thoughts...

 

Is the AuthCompute command enabled in the ChipConfig register? The ChipConfig.AuthComputeE bit must be set to 1.

 

Does the KeyConfig register for the key specify a random nonce?

 

 

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

Thanks anha6317, nice catch. AuthComputeE bit did the trick :) Thank you :)

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

Nice one :)