Assertion when trying to check state of ECC508A about eclet

[jbdatko]

Sorry for delay, I've been traveling / sick :(

It'll probably be next week until I can try this but some thoughts:

1. I never used the cryptoauth xplainend board so I'm not sure what state they ship in, but yes, I would expect the 508A/204A/132A on them.
2. I would have thought you could use the default address for eclet (without -a) flag. In fact there, might be a bug with passing in the -a...
3. The 132 is its one beast--I wouldn't expect any commands to work with it. While the 508A/204A are "sisters."
4. Lastly, while I do appreciate you using my library, it was created when Atmel's was not-so-good. They have a decent one now (http://www.atmel.com/tools/cryptoauthlib.aspx) it might take a little work to get going for linux but it's more full-featured then mine now.

[pietrushnic]

Hi @jbdatko,
thanks for reply.

1. According to schematics those chips are there, but the question is how to determine state of those chips. I don't have NDA signed yet and no documentation was exposed to me, so I can only rely what I found in internet. I have couple parts and tried 2 of them both behave the same way, so I assume this is typical. Atmel documentation describe procedure for provisioning but it requires provisioning server set on Windows and working USB keys. I get new USB root and signer keys, but none of it is visible in applications on my Windows 10 and Atmel is not helpful with that. I wrote question on Atmel forum here. I don't have way of trying basic scenarios with those modules.

2. Unfortunately without providing address eclet hangs. Strace say it loops in

write(3, "\0\0", 2)                     = -1 EIO (Input/output error)

I tried to gdb that and it looks like it hangs here:

#0  0x76f0e89c in write () at ../sysdeps/unix/syscall-template.S:81
#1  0x76f90a48 in lca_wakeup (fd=fd@entry=8) at src/i2c.c:88
#2  0x76f90cb0 in lca_atmel_setup (bus=bus@entry=0x13a94 "/dev/i2c-1", addr=96) at src/i2c.c:194
#3  0x00011fb4 in dispatch (command=0x7efff4e9 "state", args=0x7efff1b4) at src/cli/cli_commands.c:186
#4  0x000110a4 in main (argc=3, argv=0x7efff354) at src/cli/main.c:250

libcrypti2c hit that code:

LCA_LOG (DEBUG, "lca_read_sleep failed, retrying");
# and
LCA_LOG (DEBUG, "Irritably woken from peaceful slumber.");

3. I'm looking to enable ECC508A. Do you think that command interface for 132A is compatible with ECC508A ?

4. I tried CryptoAuth Lib and waste a lot of time with it, but I was not able to use it. First examples simply do not compile with recent Atmel Studio - I tried to fix that I'm not familiar with that IDE and it is no intuitive to me. They wrote examples for SAMD21 and they advertise starter kit with SAMG55. I need to make ECC508A work on embedded Linux device, but CryptoAuth Lib doesn't provide i2c HAL. I tried to write it by myself, by understanding SAMD21 code, but the problem is that converting abstraction layer of ASF to Linux i2c API was not so simple. Message format is different and there is no 1:1 conversion. I have analyzer and can reverse that, but first I have to have something working. That's why I tried to look for alternatives. I think probably best would be to have Linux driver for ECC508A. I'm not sure what would be the most effective path since there is no community to ask about this things. If you have any advice how to approach CryptoAuthLib and HAL part I would appreciate that.

BTW meanwhile I bought SAMD21 which still wait for triage with ECC508A, but at least I have hardware configuration for which examples were implemented.

[jbdatko]

Yeah, I hear you. There is very limited support :/ I am using libcrypti2c in applications and this should work with the 508A. It will definitely NOT work with the 132A-- They are by no means compatible at the command level. Generally what I do for testing is to take a 508, in SOIC-8 form, and wire it up to the pi or beaglebone. Next week I think I can try this out. I did start on a kernel module actually ( https://github.com/cryptotronix/atsha204-i2c). If you supply the address to the driver it will work with both the 204/508. I think I have compile flag in libcrypti2c to say if you are using the kernel module. It only works with one chip at a time (you can't have three /dev/atsha-X for examples). Also, I think the kernel headers changed a bit since I lasted used that but this did work. The benefit of this approach would be you could write your app in any language that can read/write to a file descriptor.

[pietrushnic]

@jbdatko I'm not sure what is correct translation of i2cdetect to what I see on PCB. PCB description say:

dev	i2c addr	wake pulse
AES	0xA0	No
SHA	0xC8	Yes
ECC	0xC0	Yes

I saw that in code i2c address is shifted one bit right, so this give:

AES 0xA0 >> 1 = 0x50
SHA 0xC8 >> 1 = 0x64
ECC 0xC0 >> 1 = 0x60

I'm not sure if this is correct and there is no 0x58, but i see it in i2cdetect output.

I saw kernel flag in documentation. I will try try your linux driver and let you know about results.

[jbdatko]

The SHA and ECC address look correct. Not sure about the AES, I have not worked with that one as much.

…

On Mon, Jan 2, 2017 at 6:02 AM, Piotr Król ***@***.***> wrote: @jbdatko <https://github.com/jbdatko> I'm not sure what is correct translation of i2cdetect to what I see on PCB. PCB description say: dev i2c addr wake pulse AES 0xA0 No SHA 0xC8 Yes ECC 0xC0 Yes I saw that in code i2c address is shifted one bit right, so this give: AES 0xA0 >> 1 = 0x50 SHA 0xC8 >> 1 = 0x64 ECC 0xC0 >> 1 = 0x60 I'm not sure if this is correct and there is no 0x58, but i see it in i2cdetect output. I saw kernel flag in documentation. I will try try your linux driver and let you know about results. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPZY3cyojE06LAH0aszOM-Q0TWW6eGGks5rOPV5gaJpZM4LTagF> .

[pietrushnic]

@jbdatko finally found time to try your kernel driver. I use 0.2 version since it seems to be newer. If I should use master please let me know.

Unfortunately it looks like wake up routine doesn't work for ECC508A (there are some additional logs so I can understand flow):

$ echo atsha204-i2c 0x60 | sudo tee /sys/class/i2c-adapter/i2c-1/new_device
[  204.617411] atsha204_i2c_probe
[  204.620655] atsha204_i2c_wakeup
[  204.623851] atsha204-i2c 1-0060: Send wake-up (1)
[  204.629430] atsha204-i2c 1-0060: Send wake-up (2)
[  204.635051] atsha204-i2c 1-0060: Send wake-up (3)
[  204.640587] atsha204-i2c 1-0060: Send wake-up (4)
[  204.646095] atsha204-i2c 1-0060: Wakeup failed. No Device
[  204.651589] atsha204-i2c 1-0060: Device failed to wake
[  204.656788] i2c i2c-1: new_device: Instantiated device atsha204-i2c at 0x60

I think that 0x60 is not correct address for CryptoAuth Xplained Pro. 0x50 give:

[  412.756299] atsha204_i2c_probe
[  412.760409] atsha204_i2c_wakeup
[  412.763886] atsha204-i2c 1-0050: Send wake-up (1)
[  412.771815] atsha204-i2c 1-0050: Chip is awake
[  412.776276] atsha204-i2c 1-0050: Wakeup CRC failure
[  412.781158] atsha204-i2c 1-0050: Device failed to wake
[  412.786391] atsha204-i2c: probe of 1-0050 failed with error 5
[  412.792220] i2c i2c-1: new_device: Instantiated device atsha204-i2c at 0x50

And 0x58:

[   53.991985] atsha204_i2c_probe
[   53.995071] atsha204_i2c_wakeup
[   53.998253] atsha204-i2c 1-0058: Send wake-up (1)
[   54.006464] atsha204-i2c 1-0058: Chip is awake
[   54.010976] atsha204-i2c 1-0058: Wakeup response OK
[   54.015854] atsha204_i2c_idle
[   54.018820] atsha204-i2c 1-0058: Send idle
[   54.024062] atsha204_i2c_register_hardware
[   54.028168] atsha204_i2c_add_device
[   54.033140] atsha204_i2c_rng_read
[   54.036483] atsha204_i2c_get_random
[   54.040045] atsha204_i2c_transaction
[   54.043635] atsha204-i2c 1-0058: About to send to device.
[   54.049030] atsha204_i2c_wakeup
[   54.052215] atsha204-i2c 1-0058: Send wake-up (1)
[   54.060087] atsha204-i2c 1-0058: Chip is awake
[   54.064539] atsha204-i2c 1-0058: Wakeup response OK
[   54.069420] Sending : 00000000: 03 07 1b 01 00 00 27 47                          ......'G
[   54.093205] atsha204-i2c 1-0058: Received from device.
[   54.098354] Received: 00000000: 23 10 ff 72 fc 69 b2 c4 14 6b 79 33 cf d6 50 94  #..r.i...ky3..P.
[   54.107277] Received: 00000010: ac cd c4 7d d4 6f 66 d1 de 3b 40 8d 9c 76 33 0d  ...}.of..;@..v3.
[   54.116178] Received: 00000020: 5f 8b 34                                         _.4
[   54.123943] atsha204_i2c_idle
[   54.126912] atsha204-i2c 1-0058: Send idle
[   54.131270] atsha204-i2c 1-0058: Returning random bytes: 16
[   54.136856] atsha204-i2c 1-0058: HWRNG result: 0
[   54.141631] i2c i2c-1: new_device: Instantiated device atsha204-i2c at 0x58
pi@raspberrypi:~ $ sudo ./test 
Wrote 4 bytes
Read 32 bytes
Received data : 0x14 0xDC 0xA3 0x78 0xD8 0x32 0xC9 0x8F 0x47 0x58 0x54 0xF9 0x4E 0xE1 0x40 0x97 0x3C 0xE3 0x89 0xD1 0x45 0x1B 0xD7 0x6E 0xDD 0xF1 0x3C 0x66 0x94 0x7F 0xEF 0x70
Starting single byte read test
Wrote 4 bytes
Received data : 0x27 0xA8 0xEE 0xF3 0xF3 0x45 0x5F 0x09 0x7F 0xB4 0xD4 0x6C 0xA4 0xFD 0xAF 0x83 0x6C 0x34 0x4F 0x78 0xF0 0xE5 0x14 0xD2 0xCF 0x7A 0x90 0x3D 0x99 0x54 0x04 0x80
Multiple open:: Device or resource busy

For SHA it look fine:

[  344.474457] atsha204_i2c_probe
[  344.477543] atsha204_i2c_wakeup
[  344.480719] atsha204-i2c 1-0064: Send wake-up (1)
[  344.490829] atsha204-i2c 1-0064: Chip is awake
[  344.495400] atsha204-i2c 1-0064: Wakeup response OK
[  344.500285] atsha204_i2c_idle
[  344.503319] atsha204-i2c 1-0064: Send idle
[  344.507728] atsha204_i2c_register_hardware
[  344.511927] atsha204_i2c_add_device
[  344.515800] atsha204_i2c_rng_read
[  344.519128] atsha204_i2c_get_random
[  344.522736] atsha204_i2c_transaction
[  344.526348] atsha204-i2c 1-0064: About to send to device.
[  344.531782] atsha204_i2c_wakeup
[  344.534929] atsha204-i2c 1-0064: Send wake-up (1)
[  344.542785] atsha204-i2c 1-0064: Chip is awake
[  344.547237] atsha204-i2c 1-0064: Wakeup response OK
[  344.552172] Sending : 00000000: 03 07 1b 01 00 00 27 47                          ......'G
[  344.584572] atsha204-i2c 1-0064: Received from device.
[  344.589719] Received: 00000000: 23 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00  #...............
[  344.598625] Received: 00000010: 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00  ................
[  344.607525] Received: 00000020: 00 41 1a                                         .A.
[  344.615289] atsha204_i2c_idle
[  344.618260] atsha204-i2c 1-0064: Send idle
[  344.623195] atsha204-i2c 1-0064: Returning random bytes: 16
[  344.628785] atsha204-i2c 1-0064: HWRNG result: 0
[  344.633593] i2c i2c-1: new_device: Instantiated device atsha204-i2c at 0x64
pi@raspberrypi:~ $ sudo ./test 
Wrote 4 bytes
Read 32 bytes
Received data : 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00
Starting single byte read test
Wrote 4 bytes
Received data : 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0x00 0x00
Multiple open:: Device or resource busy

When I compare this to CryptoAuth Lib it look like driver implement part of CryptoAuth Lib logic. I tried to implement HAL for CryptoAuth Lib but for some reason I'm getting I/O error when trying to do write correctly open i2c descriptor, same stuff happen with I2C_RDWR ioctl. At this point I cannot reproduce in user space the same flow you use in kernel space.

Is it correct to claim that ECC508A is behined 0x58 ? How I can distinguish ECC and SHA ?

[jbdatko]

So these chips can change their i2c address. I think the SHA/ECC have different serial number revisions, if you look at the SHA204 datasheet you should be able to confirm. But, it looks like the cryptoauth explained changed the i2c address of the 508? Best to find the atmel docs on the cryptoauth explained and confirm the addresses.

Also, using the windows atmel tools is extremely helpful in development with linux tools.

[pietrushnic]

@jbdatko it appears that it is possible to write user space code that works. The I/O error that I saw was because i2c core expect ACK by default what breaks wake up procedure. To avoid that behavior I2C_M_IGNORE_NAK flag is needed in i2c msg. There was also minor bug in delay method in CryptoAuth Lib after fixing that and correctly waking up device it is possible to communicate with ECC508A and get random numbers.

In that way I reached point advised at beginning - to use CryptoAuth Lib. Thanks for your time and helping me to narrow down the problem.