Provisioning and accessing the ATECC508A

Log in or register to post comments
Go To Last Post
4 posts / 0 new
Author
Message
ILF
ILF's picture
Level: New Member
Joined: Mon. Nov 21, 2016
Posts: 2 View posts
#1
Posted by ILF: Mon. Nov 21, 2016 - 02:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi. I started researching the ATECC508A IC and I have some questions. I read the basic provisioning PDF file that discusses provisioning the device to authenticate a client to a host and everything seems straight forward from a PKI point of view. However I have some questions and I would love if you are able to clarify them for me. I would like to connect the ATECC508A to a Linux devices, for the sake of the question let's assume it is something like RPi that can run a full blown Linux distro and at the same time has enough GPIOs and I2C bus to connect directly to the IC.

 

Question 1: Is there a way to provision the IC with F/OSS tools from Linux-land. If this was a smart-card, the usual path would be using pkcs15/pkcs11 tools from opensc and using openssl at some point. Is there a way where I can provision the IC while it is connected directly to the I2C bus?

Question 2: From the PDF with the node example, I can see that once the client is provisioned with the client cert and the signer cert and a private key has been generated, those are all "locked" in the devices. Does that mean that this operation can be done only once. Can the device be "formated", smartcards can be re-initialized. Also can the IC contain more than one chain of trust, lets assume for different PKI providers.

 

Question 3: If the device can hold more than one PKI chain, is there way to lock in place one of those, while we allow the extra available slots to be populated by end users.

 

So far this is what I can come up as questions. I'll order few ATECC508A right away and will start experimenting with them in Linux user land. I see that OpenSSL already supports the IC and I'll start playing around with it, but it will be a bit pointless if I can not provision the devices on my own. Note: at this point I don't want to order extra hardware so I can just provision the devices.

 

 

Tags:

Security, General Security Discussions
Top
pietrushnic
pietrushnic's picture
Level: New Member
Joined: Tue. Mar 11, 2014
Posts: 3 View posts
Location: pietrushnic
Posted by pietrushnic: Tue. Dec 13, 2016 - 11:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi @ILF,

you seem to have very similar problems to me. I wonder if you pass some obstacles and what was your experience.

 

1. ECC508A provisioning was approached by WolfSSL. Unfortunately there is no Linux i2c HAL implementation. I'm working on something, but I still don't have access to full datasheet and the only thing I can do is look into various HAL implementation which are spread across many layers and try to implement one by myself. In case of provisioning stuff you can find some work by WolfSSL contributor here: https://github.com/dgarske/atmel/blob/master/cryptoauthlib/certs/provision.c#L102. I didn't have time to dig into this, but I found ti very interesting. This seem to be only open implementation that I found despite various specs mention open protocol for device provisioning.

 

2. I think you are correct all those provisioning can be done once before locking. Those pieces are pretty cheap so this should not be big problem.

 

OpenSSL support those chips but there is no code for Linux i2c HAL. The solution may be using starer kits, but I had serious problems with passing through at least one working example.

Top
ILF
ILF's picture
Level: New Member
Joined: Mon. Nov 21, 2016
Posts: 2 View posts
Posted by ILF: Sun. Feb 5, 2017 - 01:19 AM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

sorry for replying so late. The forum was supposed to notify me when there was a reply, but it didn't. Anyway, I did not have enough time to play around with the Crypto chips from Atmel. I also just recently got a batch of them and still haven't wired any, as I have too much other work to do before I can even get to those. Here is some acknowledgement on the issues though.

 

1. I found out the same thing from the provided examples and libraries. No HAL for i2c on Linux. There is only a CDC HAL, which is a bit shortsighted, I think, although I can see why CDC would be more of mass market solution. There are a lot of devices around that implement the 508 in different tokens, keys, usb gadgets, etc, under Linux, but they all rely on a micro-controller of sorts, i.e. the u2f-zero. I am starting to think that I should just attach the 508 to one of the SAML21/D21 as I'm gonna use one of those in my project anyway and communicate with the 508 through them. This however is a pretty shitty approach, as I don't have an infinite number of serial connections available on my Linux boards. As to the provisioning, you are way ahead of me on that one, but I will start reading on the WolfSSL approach right away.

2. I still don't know if I can later provision the device with more certs/keys and format it, but that would probably can be found out after we find a way to provision it with F/OSS tools entirely.

I hope I'll be able to report shortly what I find. I wonder how hard would it be to implement a i2c HAL for Linux though :).

Top
Capt. Rob Chichester
Capt. Rob Chichester's picture
Level: New Member
Joined: Tue. Feb 6, 2018
Posts: 1 View posts
Posted by Capt. Rob Chichester: Tue. Feb 6, 2018 - 02:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was able to successfully use the HAL I2C that comes with the cryptoauthlib in our embedded Linux implementation.  I am having a broader issue with integrating the cryptoauthlib into our OpenSSL/TLS stream in order to validate the device (client) certificate.  I really do NOT want to have to rebuild OpenSSL to integrate the microchip library but I am afraid that is the conclusion that we keep coming to.  I have not gotten timely responses from MicroChip at this time.

Top