- Home
- Product Categories
- Beagle
- CryptoCape
CryptoCape
The CryptoCape is the BeagleBone’s first dedicated security daughterboard and was made in collaboration with our Hacker In Residence, Josh Datko. Known as “shields” on other platforms, a BeagleBone cape attaches to the expansion headers of the BeagleBone. This cape adds specialized ICs that perform various cryptographic operations which will allow you to add a hardware security layer to your BeagleBone project. It also is a nice device for those performing embedded security research. Needless to say this is a great product for those of you who are interested in computer security!
On board each CryptoCape is a slew of hardware fresh for your use: a 256k EEPROM with a defaulted I2C address and write protection, a real time clock (RTC) module to keep accurate time, a trusted platform module (TPM) for RSA encryption/decryption and signing in the hardware, an AES-128 encrypted EEPROM, an ATSHA204 authentication chip that performs SHA-256 and HMAC-25, and an ATECC108 that performs the Elliptic Curve Digital Signature Algorithm (ECDSA). You will also find an ATmega328p and a large prototyping area available on the board. The ATmega is loaded with the Arduino Pro Mini 3.3V bootloader and has broken out most of the signals to surrounding pads.
Each CryptoCape comes with pre-soldered headers making this board ready to be attached to your BeagleBone as soon as you get it. The only additional item you will need to get the CryptoCape fully functional is a CR1225 coin cell battery which can be found in the Recommended Products section below.
The CryptoCape is a registered BeagleBone cape whose firmware is included in the latest BeagleBone debian images. However, you may need to upgrade your image to retrieve the latest software. Check the Hookup Guide below for instructions on installing the cape firmware.
Note: A portion of each sale is given back to Josh Datko for continued development of new and exciting Cryptographic tools.
- Registered BeagleBone Cape
- Encryption and Decryption Hardware Pre-Installed
- ATmega328p Operating at 3.3V and 8Mhz
- Prototyping Area
- Schematic
- Eagle Files
- Hookup Guide
- Datasheets:
- CAT24C256 (Cape EEPROM)
- ATAES132 (AES-128)
- DS3231MZ/V+ (RTC)
- AT97SC3204T (TPM)
- ATSHA204 (SHA-256)
- ATECC108 (ECC)
- ATmega328p (m328P)
- [CCATS](https://cdn.sparkfun.com/datasheets/Dev/Beagle/Validation_Z422740 - CryptoCape.pdf)
- GitHub (Design Files)
- Product Video
CryptoCape Product Help and Resources
ERROR: "The certificate of `rcn-ee.net' is not trusted" Fix
If you see part of this error
... `rcn-ee.net' is not trusted.
when installing the tpm-tools there might be something with the clock that the Beaglebone Black uses. Try updating the time:
https://groups.google.com/forum/#!topic/beagleboard/PiYrlAUKXUM
https://www.mail-archive.com/beagleboard@googlegroups.com/msg18944.html
Core Skill: Programming
If a board needs code or communicates somehow, you're going to need to know how to program or interface with it. The programming skill is all about communication and code.
Skill Level: Competent - The toolchain for programming is a bit more complex and will examples may not be explicitly provided for you. You will be required to have a fundamental knowledge of programming and be required to provide your own code. You may need to modify existing libraries or code to work with your specific hardware. Sensor and hardware interfaces will be SPI or I2C.
See all skill levels
Core Skill: Electrical Prototyping
If it requires power, you need to know how much, what all the pins do, and how to hook it up. You may need to reference datasheets, schematics, and know the ins and outs of electronics.
Skill Level: Rookie - You may be required to know a bit more about the component, such as orientation, or how to hook it up, in addition to power requirements. You will need to understand polarized components.
See all skill levels
Comments
Looking for answers to technical questions?
We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.
Customer Reviews
3 out of 5
Based on 1 ratings:
Hey, Josh here! Thanks for checking out the CryptoCape! I'll do my best to keep tabs on the comments / questions that people have here.
Also, I'm making a series of screen casts which should help show the cape in action (with sweet command-line-action-footage :p)
UPDATE 15 JAN 2015 I know have a debian repository: http://debian.cryptotronix.com/ that has some of the software for the chips on there. It should make it a bit easier to install the software.
Happy Hacking!
For those wondering about applications... An ideal one would be if you had an autonomous public device with wireless connectivity, you could "burn in" a public key as a PKI trust anchor and only trust messages signed by a certificate that chains appropriately. You could also perform a manufacturing ritual to generate a key pair in the secure EC chip and then sign a certificate with the public key. That certificate can serve as a "birth certificate" identifying the device as a trusted component. If the signing certificate chains through to the PKI root, then all of your devices can mutually trust each other. No one would feasibly be able to weasel their way into any conversations without compromising either one of the crypto chips or your PKI root.
I think the only thing missing is a mechanism to prevent someone from physically removing the cape and then being able to use it to participate in the PKI. Some kind of anti-tamper arrangement with the host would be necessary, but it's difficult to imaging how that would be un-hackable if you assume that the BB is "untrusted" (that is, incapable of keeping a secret).
I thought about anti-tamper solutions, but given the whole open construction it's a bit difficult. The ATECC108 can either support key generation in the chip or can import a key. I have not yet implemented the later in my driver. It's on my todo list.
The idea behind the onboard ATmega was to allow for a "trusted" processor. Obviously, doesn't help if it's physically removed :) But, it can only be programmed with physically access via: 1.) the ISP header or 2.) the serial UARTs if the jumpers are on.
But yeah, spot on with your example. Thanks!
Hi Josh, i can spot an example for this, am planning using it in an anti-tamper POS device environment and looking at a situation where the POS device is screwed opened, it should indicate TAMPER alert, something like that.
That sounds like a fun application! If it tampers, what should it do? If it's going to make keys accessible, then there are few ways one can go about this. First, you'd probably want a backup battery power source which you can do by added a 3.7 Lipo to the battery access pads. Then, some sort of interrupt to trigger the tamper event. You can either have the BBB receive the interrupt, or the attached ATmega328p.
Lastly, you would need to get rid of the keys. This depends on the chip. The TPM can be wiped, but it might require an owner password. You could certainly remove the wrapped keys. The other Atmel chips don't have a tamper feature per se, but you could, depending on the circumstance, over write the key with custom software.
If you just want to know if the box has been opened, that should be a little easier :)
Actually your response solves my problem, I need all keys erased, applications erased not just the box opened.
how does the ATMEGA328 form a "trusted" processor? how would it even be used being as only the i2c is connected to the beagle?
What I mean by trusted is along the RFC 4949 definition:
Once you load firmware on the ATmega, with the jumpers off, it's difficult to change that firmware from software. So, the BeagleBone can trust the execution on the ATmega. If the BeagleBone's software is compromised, it's difficult to comprimise the software on the ATmega. I had meant it to be like a DIY TPM.
You have to implement your own i2c data format. The ATMega can act as a i2c master and/or slave. You can use the Arduino Wire libraries if you'd like. As a master, it can interface with any of the crypto chips on the board. In fact, if you provide a power supply to the board (and regulator), it is in essence, a Pro Mini.
I've found it very handy to have a MCU that is both a master and slave. You can check out my DEFCON talk where I use the ATmega as a slave device to relay messages from the BeagleBone to a PC.
I don't think we try to claim it is a trusted processor. Using the two program jumpers you can connect RX and TX to the Beagle and program the Atmega328 using it's serial boot loader. The Atmega328 was put on the board to provide some sandbox capabilities if anyone wanted to interface with secondary sensors such as fingerprint readers, or RFID readers. One idea was to hold the I2C lines low, actively inhibiting the TMP module to function until a proper RFID card was read. I believe Josh is working on some experiments related to this. Check out is site at www.datko.net
This looks configured as a top cape. Any way to get one either without headers or configured with stacking headers?
Josh here again. If you want to see a cool project on how to use the BeagleBone Black and CryptoCape as a NSA-like hardware implant, check out my DEF CON 22 presentation.
Hey Josh, well done to you and SF for getting this out. Can you provide a link to where you keep the example source code for controlling all the features on all of the devices on this cape? Also, it may be worth explaining to folks why the above datasheet for the TPM is a bit spartan.
I wrote my own implementations for the ATSHA204 and ATECC108 which are available on Github here and here. Examples are on GitHub as well.
One very important note on the software. These chips have some one-way fuses on them that lock parts of memory. If you read the ATSHA204 datasheet, all 90+ pages, it's quite a feature-full chip. My software has assumed, what I consider, reasonable defaults for most users. Once you personalize the device it can't be undone.
/me thinks some screencasts would help...
The script to flash the ATmega from the BeagleBone is here. In order to flash from the Beagle you are going to need male headers and two jumpers. Be sure to read the hookup guide on programming the ATmega, especially if you decide to do it with an external programmer.
I have not yet written a driver for the ATAES132. Atmel does release an AVR library.
The TPM uses existing software. The TL;DR is that using the TPM is complicated. Typically TPMs are reserved for laptops with a bios. This is the first hobbyist usage of an embedded TPM (AFAIK), so I'm collecting what I know here.
re the datasheet: The TPM and ECC108 datasheets are under a NDA and I realize this is annoying. For the TPM you really don't need it because it conforms to the TPM 1.2 spec which is provided by the TrouSerS software. Likewise with the ECC108, atmel releases it's source code or you can use mine.
The RTC and EEPROM use existing Linux drivers.
The hookup guide also has additional information on the EEPROM and installing the firmware.
Thanks for the questions; hopefully that helps!
How hard is it to get NDA signed and get access to the datasheets? I would be interested but I am a bit concerned about inability to get access to full data sheets
You can go to your local Atmel distributor and ask that way. I don't want to discourage you but I've heard that Atmel is reluctant to give the datasheet to individuals (i.e. not companies or organizations).
I realize this is annoying. I tried to pick chips that at least had existing software. The TPM has the TrouSerS stack and Atmel releases code for the ECC108 for AVR or you can use what I have for Linux. Atmel's code has examples on how to perform various operations. Also, you can download their free crypto tool called ACES which will show the memory contents of the chip. However, you will need the non-free (about $100) "microbase" adapter.
Thanks for the question and the interest.
I appreciate your honesty.
I find it hilarious that security products are protected by NDA. Gives one (miss)impression that the products are not that secure if you know the details.
I know, being a open source guy myself, it's a bit conflicting. And don't get me started on U.S. Export controls. None of the chips are made in the U.S. So we import them and then we have to ask permission to send them back out. I should really complain to my Congressman, I mean, this obviously encourages "off-shore" manufacturing.
Might you consider changing out the DS3231MZ/V+ part for at least the DS3231M+ if not the DS3231 ? Presently the board uses the cheap MEMS part rather than a decent Xtal based version and the 8pin package simply lacks the thermal mass for best stability. While the DS3231MZ/V+ is still MEMS based rather than Xtal based moving to either part in a 16pin package helps accuracy and stability. Also placing a ground plane on the topside of the board under the DS3231* can be helpful. So long as it's connected to a larger ground pour on the board this also serves to increase thermal mass thus decreasing thermal drift while also isolating the chip from other signals that may run underneath (as noted in the datasheet). Basically I figure if you're going to include a RTC, the RTC ought be as good as is practical. Moving to the DS3231M+ is a step in the right direction but we can do better without much increased cost. This because in some applications of this cape accuracy in timing could become quite important. (thinking about applications in trusted time stamping and digital signatures where one need prove that events happened at specified times or in a specified sequence)
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.
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.
Looks like a great board for it's intended use. The bus select option involves adding 2 more 3 way solder jumpers and took less than 5 minutes to add and place in eagle (yea sparkfun for making those available!) Heck, I'll send ya the revised board files.
Are you saying provide the ability to move all chips from one bus to another or allowing each chip to have a bus selector? The first may be doable but the second seems unnecessary. Most of the devices are not accessed at high frequency. I think a little more research would have revealed that the board is not a crypto accelerator.
I just mean moving all the crypto chips on the cape as one between i2c1 and i2c2 such that the cape crypto functions as a whole can be moved to either i2c bus. personally I think this is an option that ALL I2C based capes ought incorporate. I get now that this board is not intended as a crypto accelerator. some good examples of what and how it might be used in the description would be good though. (give it a minute or so & you'll see what I'm thinking.)
Moving the bus is an interesting proposition. If it were to be done we might want to look at a DPDT switch. Jumpers open the possibility of mis-attached buses. Thanks for the input!
The last time I did the BOM arithmetic for a DPDT switch for signal routing, it turned out to be cheaper to slap in a TTL mux chip. Then you don't have the issue of inconsistent jumpers, because there is only one jumper needed to throw the mux, or in my case, I ran it to an I/O pin so that it was under software controlled configuration. Of course, in this case we are talking I2C signals so it isn't quite like uni-directional logic signal routing -- but the idea stands, I think. Look for a suitable mux chip, it would probably be cheaper than a physical switch, certainly more reliable, and opens the possiblity of software selectability (if you want to burn an I/O pin on that function).
I guess a solder bridge across the entirety of a 3 way solder jumper could short I2C1 & I2C2 together given poor soldering but a physical header jumper ought make that difficult with the bus to the board being the center and the beagle header being one side or the other. note though, per the beagle srm the cape eeprom needs to stay on I2C2.
Another use of the Cryptocape for those wondering is to store the key for a tor location-hidden service and to assist with key generation in the first place. Hidden services let people visit your website anonymously and help people in repressive countries evade censorship, which is even more important after China recently started attacking Github.
I wrote about my experience using a Beaglebone to host a hidden service and although I didn't use the cryptocape, it'd be a perfect place to store the hidden service's private key securely as well as keeping accurate time to prevent clock-skew attacks since the cape has a RTC module.
The description of this cape says the TPM is the Atmel AT97SC3204T and links to the summary data sheet for the AT97SC3204 (not the I2C but the LPC bus model instead). The "hookup guide" says it's the Atmel AT97SC3205T and links to that datasheet ... If I buy one, which TPM will be on it?
Good catch and sorry about the confusion. It's the AT97SC3204T. The 'T' indicates 'TWI', which is I2C. The AT97SC3205T is the "newest" Atmel TPM which is a bit nicer IMHO (no external oscillator and some other improvements) but it's still not in distributor inventory.
I think the problem was finding the summary datasheet, which doesn't really you tell you much anyway.
What is the ATMEGA328 used for on the board? It seems to be attached only to the headers on the cape with the exception of being connected to I2C2.
There's another comment that explains the reason for the AtMega328: sparkfun.com/products/12773#comment-5388e578757b7f392f8b4567
Hello, Has anyone got the TPM working on this shield? I can get it to load on a BBB in Ubuntu and the TPM tools work, but I want to enable secure boot, with Uboot. Any ideas???
Thanks SJJ
Thanks for checking out the cape! First of all, you should make sure that you cleared your compliance vectors using this script. Otherwise, you'll have test keys, which is not what you want.
Here's how I'd go about getting uboot with the TPM to work with uboot to implement secure boot:
The only TPM aware uboot is libsboot. You need to use that.
There is a bug with the above. We believe it is a uboot bug. The TPM on the CryptoCape is tied to what the AM335x calls i2c2. i2c2 does not work in uboot. You can either: fix the uboot bug or physically move the TPM to i2c1. To do this, you must remove the cape and fly-wire from the other i2c bus to the cape. However, when you do that, the EEPROM will no longer be read on application boot and the cape device tree overlay will not be loaded. If you physically move it, in application space you can instantiate the TPM driver manually or with a systemd/init script.
For full effect, you need to rebuild your kernel with IMA.
Good luck!
Josh
Any updates on International shipping?
I know of international customers who received their boards. I don't know exactly what the order process is though. Either you contact SparkFun first or you checkout and then they'll contact you if they see an international shipping address.
Because it's export controlled, I think they just need to make sure that you won't re-export it to North Korea, Iran, Syria, etc...
I see this as a good board for me to implement UN (unpredictable Number) in the EMV kernel application for EMV chip cards am currently working on on BBB, does anybody here also have an hints...
It looks like the EMV UN is a 32 bit number? If that's the case, all the crypto chips have a RNG that will return 32 bytes of random data. The BBB has a RNG in the SoC as well. You'll want to upgrade the kernel to 3.13 to use the OMAP drivers for it others you'll have to backport the driver.
This, assuming you just didn't want to use linux's /dev/(u)random interfaces.
Thanks jbdatko, you are right, EMV UN is a 32bit numbers, i don’t want to use linux’s /dev/(u)random interfaces for the RNG, so like you suggest i prefer the one in the crypto chips of the cryptoCape since i can also handle secure boot from there, secure boot process is close to EMV UN generation process. I might need your assistance during the implementation, i haven’t gotten the cryptoCape yet.
To make secure boot work on the BBB, you'll need modified version of uBoot. You should also recompile the kernel to add Integrity Measurement Architecture (IMA).
Of course, this is much easier said then done. There are some smart people that hang out at the #cryptotronix channel on freenode and you are welcome to ask there.
Is the work needed for the export restriction controls for crypto the reason for not shipping it out of the country?
Yes, but SparkFun is applying for the ECCN and it's submitted to the USG. They are still waiting for the response. The government moves at the government's pace...
The BeagleBone Black had to go through a similar process for export, see: http://elinux.org/Beagleboard:BeagleBoneBlack#Export_Information
Do the individual IC's each have their own ECCN? Can the individual IC's be exported by themselves? If so that should do 2 things. First it ought to make getting an ECCN for the board easier, and second one could conceivably export all the individual components and build the boards elsewhere until the ECCN for the board is in place. Gotta love Govt. rules and policy.
The 4 Atmel Crypto chips each have an ECCN. In our first round with the Govt. they reminded us that "the individual ECCN of the components influence, but do not determine the overall ECCN." It'll be review on its own and a new product.
I've heard from some Europeans that Digikey won't ship the chips to them. The intention with this board, I believe, is to sell it internationally once approved.
For the record and to get things straight, the only chip which has US export restrictions is the ATAES132. Also to get things straight, all the chips on that board cost exactly 23.86USD if bought from Mouser (or DigiKey, if you so prefer) in single quantities, today. SparkFun's volume discount obviously drove that number way lower.
So, with all due respect, where do the rest of 59.95 - 23.86 = 36.09USD go?
You might have forgotten the PCB, headers, assembly time, engineering time, testing time, and the portion of sales that helps Mr. Datko continue to support this.
The headers are 0.95USD each (so 1.9USD for both, though we both know you get them for close to nothing), the PCB is 2.5USD each in 10x quantities (or less, since you've got it pipelined). This leaves us with 36.09 - (2.5 + 1.9) = 31.69USD.
Comparing with DEV-12774, which probably used a comparable amount of engineering and assembly time (laying out those prototyping holes in a perfect matrix is about the complexity of laying some 5 chips on the same I2C bus) and costs 9.95USD; I would concede that Mr. Datko gets 20USD and the remaining 11.69USD are meant to be the engineering and assembly costs.
Finally, "engineering" is usually a term reserved for creative or complex work which is not immediatly straightforward and requires combining experience, expertise and talent. I don't want to sound mean, but if a true engineer at SparkFun would have an apprentice, and the apprentice would have an intern, laying out this board would be the kind of warm-up exercise the intern would do right after having their morning coffee.
We welcome constructive criticism, but this has crossed the line into trolling. Consider this your only warning.