The CryptoCape is now available at SparkFun Electronics

[Joshua Datko]

The CryptoCape, a collaboration between SparkFun and myself, is now available for purchase at SparkFun Electronics [1]. In short, the cape adds some hardware crypto chips, a RTC with battery, and an ATmega328p which is designed to be flashed from the Beagle. It will be officially announced on the "new products Friday" post tomorrow, but I think this group deserved an early announcement.

Thanks to BeagleBoard.org for making a great platform and special thanks to Robert Nelson for backporting the TPM driver to 3.8. 

This community is awesome; I've learned so much by following this list. Thanks to everyone who shares their time and knowledge.

There's only 1 left :)

Happy Hacking!

Josh

[1] https://www.sparkfun.com/products/12773

[Joshua Datko]

It's a cape that has the following security ICs on the Beagle's i2c2 bus:

- Atmel TPM (RSA 2048)

- Atmel ATSHA204 (SHA/HMAC256)

- Atmel ATECC108 (ECDSA)

- Atmel ATAES132 (AES-128-CCM)

Plus an EEPROM and a 5pmm RTC.

It also contains an ATmega328p, which is loaded with the 3.3V pro mini bootloader. The ATmega is also connected on the i2c2 bus so the Beagle and the 328p can communicate over i2c.

Also, you can upload sketches from the Beagle's UART4 to flash the ATmega.

The SparkFun product page is here, with a hookup guide: https://www.sparkfun.com/products/12773

The eLinux page is here: http://elinux.org/Cryptotronix:CryptoCape

The SparkFun page talks about each IC in more detail.

Josh

On Thu, May 29, 2014 at 5:23 PM, rh_ <richard...@lavabit.com> wrote:

On Thu, 29 May 2014 16:17:53 -0700 (PDT)
Joshua Datko <jbd...@gmail.com> wrote:

> The CryptoCape, a collaboration between SparkFun and myself, is now
> available for purchase at SparkFun Electronics [1]. In short, the
> cape adds some hardware crypto chips, a RTC with battery, and an
> ATmega328p which is designed to be flashed from the Beagle. It will
> be officially announced on the "new products Friday" post tomorrow,
> but I think this group deserved an early announcement.

What is it?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/NhMSP9ywlzg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Fort]

ok, the data interface for all these chips sits in the i2c bus, so it looks like for much real encryption work this cape will be really slow, bottle necked and constrained by the chosen bus and it's bandwidth.  I might also suggest for a rev 2 adding a set of 3 way jumpers such that it can sit on either i2c1 or i2c2. the inclusion of solder jumpers for pullups or not on the i2c bus was a good choice.  I also fail to see what this cape does or assists with that the AM3358/AM3359 does not already do with it's on board cryptographic abilities  which do at a minimum AES, SHA, & MD5, and possibly others.

Eric

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Joshua Datko]

Hey Eric, thanks for the question, where did I read that before ;)

Thanks for the recommendation, I’ll look into the bus select option.

The goal of this board is not to provide cryptographic acceleration, because you are correct, the AM335x does have accelerators already (drivers in 3.13). The purpose rather, is to provide key isolation. So the RSA/ECC/MAC keys stay in the respective chips. For ECDSA for example, the private key never leaves the chip. In the AM335x case, you’d have to provide the key somehow in software.

Also, the AM335x doesn’t have any asymmetric crypto options. The TPM provides RSA-2048 and the ECC108: ECDSA with three NIST curves.

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/NhMSP9ywlzg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Eric Fort]

yes, yes, it may have been posted in 2 places.....  If you'd like to see the revised board files I'll pass them along.  It took all of 5 minutes in eagle to make the update and add 2 more 3 way solder jumpers (or change them to header type jumpers for ease of end user configurability for slightly increased parts cost....  thinking I'll go back and add both in parallel and the header version can remain unpopulated or filled later at user descretion.

Eric

[Mike]

How is the RTC implemented at the software level? More to the point
perhaps, how early in the boot process does the system time get set from
(presumably) rtc1?

About a month or so ago I setup a battery backed RTC, along with a
fairly current systemd. Systemd have chosen to rewrite hwclock and last
I looked it still only honored/used rtc0. Perhaps I didn't explain the
situation good enough on the systemd mailing list, but I couldn't seem
to get past anyone not understanding why a board wouldn't have a battery
backed RTC on board. Having said all that I did get it working just
using init.d scripts. Just seems like such an ugly hack when the whole
point of systemd is to essential do away with all the scripts.

The board looks like something very interesting to explore. I'm sure
one will find its' way here when cash flow permits.

Mike

[Joshua Datko]

The RTC uses the ds1307 kernel driver and you're correct, it shows up as rtc1. It is loaded when the capemgr instantiates the device tree, since the driver is in the CryptoCape DTS file. So you shouldn't need any init.d/systemd scripting it should "just work"TM.

You'll have to set the clock once and then it should hold pretty well. In testing think I had a bum battery b/c it depleted rather quickly. Once I changed batteries it seems to be holding steady. 

--
For more options, visit http://beagleboard.org/discuss
--- You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/NhMSP9ywlzg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.

[Mike]

On 05/29/2014 09:31 PM, Joshua Datko wrote:

The RTC uses the ds1307 kernel driver and you're correct, it shows up as rtc1. It is loaded when the capemgr instantiates the device tree, since the driver is in the CryptoCape DTS file. So you shouldn't need any init.d/systemd scripting it should "just work"TM.

Yes, this is nearly identical to the setup I did.  Created a dto for the ds1307, loaded it at boot, all good.  The device is there, it has very good time.  The system still needs to be told to *use* that time.

If memory serves Robert updates a time value that gets loaded so if your on a fairly current image your time is somewhat current.

I'll be more than happy to RTFM, or experiment if pointed in the right direction.  I've not seen any indication that simply adding a battery backed RTC, loading it via capemgr will cause the system (kernel) to use that device for obtaining a somewhat sane time value.

Mike

You'll have to set the clock once and then it should hold pretty well. In testing think I had a bum battery b/c it depleted rather quickly. Once I changed batteries it seems to be holding steady. 

On Thu, May 29, 2014 at 7:28 PM, Mike <belly...@gmail.com> wrote:

On 05/29/2014 07:17 PM, Joshua Datko wrote:

The CryptoCape, a collaboration between SparkFun and myself, is now available for purchase at SparkFun Electronics [1]. In short, the cape adds some hardware crypto chips, a RTC with battery, and an ATmega328p which is designed to be flashed from the Beagle. It will be officially announced on the "new products Friday" post tomorrow, but I think this group deserved an early announcement.

Thanks to BeagleBoard.org for making a great platform and special thanks to Robert Nelson for backporting the TPM driver to 3.8.

This community is awesome; I've learned so much by following this list. Thanks to everyone who shares their time and knowledge.

There's only 1 left :)

Happy Hacking!

Josh

[1] https://www.sparkfun.com/products/12773

How is the RTC implemented at the software level?  More to the point perhaps, how early in the boot process does the system time get set from (presumably) rtc1?

About a month or so ago I setup a battery backed RTC, along with a fairly current systemd.  Systemd have chosen to rewrite hwclock and last I looked it still only honored/used rtc0.  Perhaps I didn't explain the situation good enough on the systemd mailing list, but I couldn't seem to get past anyone not understanding why a board wouldn't have a battery backed RTC on board.  Having said all that I did get it working just using init.d scripts.  Just seems like such an ugly hack when the whole point of systemd is to essential do away with all the scripts.

The board looks like something very interesting to explore.  I'm sure one will find its' way here when cash flow permits.

Mike

--
For more options, visit http://beagleboard.org/discuss
--- You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/NhMSP9ywlzg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Eric Fort]

Are you guys talking about the crypto cape or the RTC cape?  The crypto capediscussed in this thread uses a ds3231 not a ds1307.  Also why anyone *needs* the rtc cape I don't get.  just keep the rtc rail powered on the processor.  That I believe is a software issue.

Eric

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Joshua Datko]

Eric,

You are correct, the CryptoCape has the DS3231. However, it use accessed via software via the ds1037 kernel driver. That driver is compatible with the 3231: http://lxr.free-electrons.com/source/drivers/rtc/rtc-ds1307.c, line 36. I haven't tried any of the other features like the Time of Day alarm so I'm not sure if that's supported with this driver.

I put the battery on the CryptoCape so that the RTC will maintain time [1] when the cryptocape is physically removed from the Beagle and [2] when the Beagle is not connected to power.

Thanks for the questions!

To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Mike]

On 05/29/2014 10:01 PM, Eric Fort wrote:

Are you guys talking about the crypto cape or the RTC cape?  The crypto capediscussed in this thread uses a ds3231 not a ds1307.  Also why anyone *needs* the rtc cape I don't get.  just keep the rtc rail powered on the processor.  That I believe is a software issue.

Eric

The Cryptocape RTC is what I was specifically asking about.  The ds1307 modules handles several rtc chips.

enum ds_type {
        ds_1307,
        ds_1337,
        ds_1338,
        ds_1339,
        ds_1340,
        ds_1388,
        ds_3231,
        m41t00,
        mcp7941x,
        rx_8025,
        last_ds_type /* always last */
        /* rs5c372 too?  different address... */
};

I'd be happy to pursue keeping the rtc rail powered.  I have no clue where this is or would be handled in software.  I'm far from being any kind of good programmer, and know far to little about hardware at this level.  Just a long time sys admin willing to learn it if pointed in the right direction.

Mike

On Thu, May 29, 2014 at 6:31 PM, Joshua Datko <jbd...@gmail.com> wrote:

The RTC uses the ds1307 kernel driver and you're correct, it shows up as rtc1. It is loaded when the capemgr instantiates the device tree, since the driver is in the CryptoCape DTS file. So you shouldn't need any init.d/systemd scripting it should "just work"TM.

You'll have to set the clock once and then it should hold pretty well. In testing think I had a bum battery b/c it depleted rather quickly. Once I changed batteries it seems to be holding steady. 

On Thu, May 29, 2014 at 7:28 PM, Mike <belly...@gmail.com> wrote:

On 05/29/2014 07:17 PM, Joshua Datko wrote:

The CryptoCape, a collaboration between SparkFun and myself, is now available for purchase at SparkFun Electronics [1]. In short, the cape adds some hardware crypto chips, a RTC with battery, and an ATmega328p which is designed to be flashed from the Beagle. It will be officially announced on the "new products Friday" post tomorrow, but I think this group deserved an early announcement.

Thanks to BeagleBoard.org for making a great platform and special thanks to Robert Nelson for backporting the TPM driver to 3.8.

This community is awesome; I've learned so much by following this list. Thanks to everyone who shares their time and knowledge.

There's only 1 left :)

Happy Hacking!

Josh

[1] https://www.sparkfun.com/products/12773

How is the RTC implemented at the software level?  More to the point perhaps, how early in the boot process does the system time get set from (presumably) rtc1?

About a month or so ago I setup a battery backed RTC, along with a fairly current systemd.  Systemd have chosen to rewrite hwclock and last I looked it still only honored/used rtc0.  Perhaps I didn't explain the situation good enough on the systemd mailing list, but I couldn't seem to get past anyone not understanding why a board wouldn't have a battery backed RTC on board.  Having said all that I did get it working just using init.d scripts.  Just seems like such an ugly hack when the whole point of systemd is to essential do away with all the scripts.

The board looks like something very interesting to explore.  I'm sure one will find its' way here when cash flow permits.

Mike

--
For more options, visit http://beagleboard.org/discuss

--- You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/NhMSP9ywlzg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike]

Changed subject as this is getting away from Joshua's original post about the CryptoCape.

On 05/29/2014 10:01 PM, Eric Fort wrote:

Are you guys talking about the crypto cape or the RTC cape?  The crypto capediscussed in this thread uses a ds3231 not a ds1307.  Also why anyone *needs* the rtc cape I don't get.  just keep the rtc rail powered on the processor.  That I believe is a software issue.

Eric

From TI User guide on the TPS65217 [1] I find this.

TPS65217C is also targeted at the AM335x processor in the ZCZ package,  but the DCDC1 output voltage is set to 1.5 V to supply DDR3 memory.  This version does not support AM335x RTC-only operation.

Gerald has stated before that there *isn't* a battery backed RTC available.  Why would I even question this, faulty memory on my part perhaps?

The question that still nags me is how does one set a sane time value from a battery backed RTC as early as possible during bootup.  Systemd only supports setting the time from rtc0, no options to specify any other device.  Sillyness IMNSVHO...

I probably have already answered my own question, just use a shell script ala init.d and be done with it.

Mike

1. http://www.ti.com/lit/ug/slvu551h/slvu551h.pdf

[Eric Fort]

The documentation and datasheets on this seem contradictory at best.  You are correct in quoting http://www.ti.com/lit/ug/slvu551h/slvu551h.pdf in that it states, "TPS65217C is also targeted at the AM335x processor in the ZCZ package,  but the DCDC1 output voltage is set to 1.5 V to supply DDR3 memory.  This version does not support AM335x RTC-only operation."  However reading the data sheet for the TPS65217C found here, http://www.ti.com/lit/ds/symlink/tps65217c.pdf , one finds on page 15 the difference between the sleep and the off modes of operation wherein the setting of the OFF bit in the STATUS register determines the state that is entered and what rails remain up.  if one enters sleep, the RTC rail looks like it stays up with all other rails down (escentially hibernation) with darn near zero power usage.  I'm hoping to find the relivant source in the next couple days (sources for pm-hibernate, pm-sleep, shutdown, halt, etc. and the kernel sources) that invoke these states.  It looks like just maybe a bit of an appropriate software hack (never going to off state, but only to sleep) could eliminate the need for off board / off chip RTC.

Eric

--

[emck]

I'm trying to interface to the ATECC108 but I'm not running linux.  Main issue I've run into is trying to wake up the chip, which requires holding SDA low for at least 60 usec.  This is tricky because the AM335x I2C controller won't send any data to the bus without sending an address first, and if it doesn't get an ACK after sending the address it won't send any data, just aborts the transaction with a STOP condition.

In the libcrypti2c code you have a function ci2c_wakeup() that sends two 0 bytes to the device.  How do you get the AM335x to send those bytes, if the device is asleep and thus won't ACK the address?  Or are you doing the same thing I've found, which is that the low bits in the device address happen to hold SDA low just long enough to wake up the chip?  (I keep hoping there's a better solution, not involving any bitbanging.  Maybe there isn't.)

[Joshua Datko]

Thanks for the question, but I don't think you will like my answer:

the ci2c_wakeup as you have discovered is indeed a hack. I looked into to a cleaner way to do this. My conclusion was that to produce a "proper" wakeup signal I'd have to mux the SDA pin to a GPIO mode to pull it low and then mux it back to I2C to use the I2C controller.

I had also considered connecting a different GPIO pin to the SDA line with the sole purpose of pulling that low for the wakeup. But that seemed more hackish than what I was currently doing.

In the end, the two bytes of zeros seems to reliably, albeit hackishly, do the trick for me when I'm using linux.

Josh

On Mon, Jul 21, 2014 at 12:22 PM, emck <beth.t...@gmail.com> wrote:

I'm trying to interface to the ATECC108 but I'm not running linux.  Main issue I've run into is trying to wake up the chip, which requires holding SDA low for at least 60 usec.  This is tricky because the AM335x I2C controller won't send any data to the bus without sending an address first, and if it doesn't get an ACK after sending the address it won't send any data, just aborts the transaction with a STOP condition.

In the libcrypti2c code you have a function ci2c_wakeup() that sends two 0 bytes to the device.  How do you get the AM335x to send those bytes, if the device is asleep and thus won't ACK the address?  Or are you doing the same thing I've found, which is that the low bits in the device address happen to hold SDA low just long enough to wake up the chip?  (I keep hoping there's a better solution, not involving any bitbanging.  Maybe there isn't.)

[emck]

'Sokay, it's some comfort to know I'm not missing a glaringly obvious solution.

If you happen to have a scope on the bus someday, I'd be curious whether those two zero bytes actually get out to the bus though.

What clock rate are you running?

[Joshua Datko]

I've seen them get out on a logic analyzer. I *think* it's using the fast speed of 400kHz? But I always get confused on the speed and like you said, I'd have to measure it to be sure.