The CryptoShield is a dedicated security peripheral for the Arduino and was made in collaboration with a previous Hacker In Residence, Josh Datko. This shield adds specialized ICs that perform various cryptographic operations which will allow you to add a hardware security layer to your Arduino 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 CryptoShield is a slew of hardware fresh for your use: 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-256, and an ATECC108 that performs the Elliptic Curve Digital Signature Algorithm (ECDSA). Unlike its cousin, the CryptoCape, we've shrunk the prototyping area but added an RFID socket that works best with a ID-12LA module.
Each CryptoShield will need to have headers soldered on once you receive it. We prefer to give you the choice of soldering on stackable or non-stackable headers, whatever fits best for you project. The only other items you will need to get the CryptoCape fully functional are a dev board that supports the Arduino R3 form-factor and a CR1225 coin cell battery. All of these additional parts can be found in the Recommended Products section below.
Note: A portion of each sale is given back to Josh Datko for continued development of new and exciting Cryptographic tools.
This skill defines how difficult the soldering is on a particular product. It might be a couple simple solder joints, or require special reflow tools.
Skill Level: Noob - Some basic soldering is required, but it is limited to a just a few pins, basic through-hole soldering, and couple (if any) polarized components. A basic soldering iron is all you should need.
See all skill levels
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
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
We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.
Based on 1 ratings:
Easily integrated with the Arduino, has several chips to explore. A lot of fun to be had with this one!
Too bad they don't make them anymore... :>(
Why was this shield discontinued?
I can't find a hardware security solution for Arduino anywhere but this. Is there somewhere I can look to add security to Yuns, Tians, etc.?
Slow sales were one of the reasons, but the main reason was that a couple of the ICs on the board are no longer being made.
Did anyone really use this shield to create a "Hello World" project? It looks like in order to initialise the crypto authentication devices I need to initialise them using some kind of beaglebone black or some raspberry pi that has I2C access. If I am wrong please correct me. Josh Datko, do you have a Hello World project that you used to Cryptoshield for?
Is this compatible for use with the Arduino Mega 2560?
I pretty much put down Arduino the day my Uno got bricked so I'm either looking at buying a second Arduino (double as ISP) but then if I'm going to do that, I know from past experience that the Uno starts to run out of room quickly so I'm considering the Mega.
No, you can't use it on Mega. This one only fits on Uno or Uno kinda devices. By the way, did you start a project based on this?
Not sure if Josh (or anybody else) noticed this, but this RTC consumes up to A THOUSAND TIMES more power than a conventional one, with a crystal instead of a MEMS. It's also an order of magnitude more expensive than, say, a PCF85263A, which can be calibrated to the same accuracy. Since you'll have to change the battery for the DS3231M every couple of months anyway, and will have to set the clock again, there's no use in having an accurate RTC like this anyway :-).
The PCF85263A is only 99 cents in one-off from Digikey? Dang I'm sold. Too bad they only have the DFN package in stock right now. I never really liked the DS1307, I hope this proves to be a good alternative.
Great, you're my first follower! :-) The package is one reason why I would like SFE to make at least a breakout board for the PCF85263A, preferably a data logger shield (SD-card + RTC + breadboarding area). Of course the breakout board should include the battery, and above all the crystal (which should be as close as possible to the IC). And hopefully Adafruit is listening too. Spread the word! :-)
I think I'm the only one who likes that RTC :)
Somebody just pointed me to PCF85263A yesterday. That one has a watchdog feature which I think this guy doesn't have, which is cool. Although you could set alarms and emulate that with Time-of-Day alarms but it's not quite the same...
I was looking for something to hold time in the weeks/month offline use-case. I initially thought the stability of a mobile-type project would be interesting an this RTC is automotive rated, but maybe not many people are using in shaky situations ;)
Frankly, I don't know why people always come up with Maxim/Dallas RTCs. They're lousy AND expensive. Both SparkFun and Adafruit chose the DS1307 (for a BoB and data logger shield resp.) While the PCF85263A is only a year old, XNP has had a few dozen excellent RTCs since years.
It looks like the DS3231M (not just the automotive version) was designed for applications which are most of the time connected to a main power supply, whether mains power or a car battery. They mention power meters in particular in the datasheet.
If you heard about the PCF85263A yesterday, that may be because I'm actively lobbying for it here :-). I'd love to see it on an equivalent for Adafruit's data logger shield here, and maybe a future version of the CryptoShield as well. Not just better features, but a LOT cheaper too. In your defense I'd like to add that the RTC was probably not your main concern; I understand that you're more the security guy.
See also http://nenya.me/electronics/rtc.php
Really nice idea but I cannot in all honestly recommend its use where ECDSA is concerned because the quoted device ATECC108 is outmoded and only support the NIST ECC curve (Yes the one the NSA 'suggested' the initial arguments for).
There is a replacement device ATECC108A that as well as the Bad NIST ECC P256 also supports B283, and K283 Elliptic Curve Support. But for confidence I would only support a device that at least gave supprt for Daniel J. Bernstein's Ed25519 curve where the arguments chosen are done so for transparent and goood cryptographic reasons.
Sounds like I'm not the only one getting into ECC these days :)
Thanks for bringing this up. I would really like to see a similar IC with Ed25519 support. I think if the demand signal increases for this curve manufactures will start to pay attention.
While I'm putting in my wishlist for curves, I'd also like an IC that did secp256k1 so that it could store Bitcoin keys. If a certain manufacture made a curve that supported both I would think that would be a very popular IC.
And while I'm asking for things, it would be great to have an IC that supported the NaCl ciphers too!
There is actually a very cool Open Source Hardware project going on called Cryptech where they are making a full HSM device. It is a very exciting project and I can't wait to get my hands on one! (I think they are in early design development now).
The 108A is a very nice enhancement to the 108. They are a bit hard to get now though but it's a pin-for-pin replacement for the 108 so we could swap it out in a later revision.
Cool idea! I purchased one.
But at $59 before the headers and Arduino, does the Yun make a better option? You can push all encryption off to the linux on a chip.
You certainly could. If that's what you want to do it'd be cheaper to buy a Pi2 and do that :)
The value, IMHO, of the shield is playing with specific crypto ICs. The other feature that's nice, with the ATECC108, is that the chip will generate a private key that can't be read. It can still be used for signing, but it would be very difficult for that key to be compromised by some extraction method.
There is a difference between message encryption and security. I contend that you almost never need to hide (encrypt) your messages, just secure them so the cannot be changed without being noticed.
For security you can use a message hash and a shared password.
check my article http://www.forward.com.au/pfod/secureChallengeResponse/index.html which uses the compact SIPHASH on arduino, all done in software.
https://github.com/sparkfun/CryptoShield is a 404. Any examples that talk to these chips available for Arduino?
The Arduino library, which is a WIP, is here. Be sure to checkout the hookup guilde because some of the chips are a lot easier to (currently) work with on a Linux board that supports the R3 footprint.
My library is essentially a wrapper around Atmel's library. I haven't exposed all the features of their library yet, but it does build in the Arduino IDE and exposes some basic commands.
What functionality works currently with the Arduino? I ask because the Arduino is featured in all the photos and the video, but everything seems to be a work in progress.
As of 28 April, this is the run down:
ATECC108 (examples). There's really only one killer feature here and it's signing. The signing example works as per the example. The trick is, first you need to personalize the device, which I should have an example up for this soon. The code is there and kinda-ish works. It completely works on a Linux board, I just need to fix some bugs on the Arduino code.
See above for ATSHA204. The trick with the ATSHA204 is that you need to load MAC keys. MAC keys are only good if somebody else has a copy or can derive them. So, to personalize with Arduino is a bit tricky because it's a one-shot deal and you must save of the MAC keys. It's much easier to personalize with linux (in both the ecc108 and 204).
ATAES132 is an Atmel Studio Library only.
Both the 108/204 also have a Atmel Studio library which you can use.
The TPM honestly going to take some serious programming effort on the Arduino as explained here. I don't plan to port a TPM driver to a 328p any time soon. Linux is hands down, the way to go.
The RFID socket has an example sketch.
The RTC needs an external lib, something like this.
If you are curious on following the development of the 204/108 library you should follow the GitHub repo.
Oof. Looking at the commit graph, it doesn't seem to be getting much love lately (April commit is just to README).
Try again, the repo was set to private.
Why can't you ship this board to outside US? Is it because of export restrictions on the chips?
Yes. We are applying for the commodity encryption paperwork, but until that comes in we can't export it. It's government paperwork and the CryptoCape took a month or two after the product launch for the certificate.
/begin rant
I would really like to see this changed. This is, IMHO, a horribly outdated law that doesn't make sense anymore. I believe it's the case that each of this ICs are actually imported into the U.S. but when you combine them into a new product, well that's a new product. So then we have to follow U.S. export laws.
/end rant
...not to mention you can implement a lot of this stuff in software (you're going to be using a library anyways to interface the device).
The concept of a dedicate hardware crypto device is novel, but not at this price point, and especially not for prototyping. After all, much crypto can be learned and done in code, which is free. I'd much rather see these components broken out into individual ICs that we cherry pick and wire into our own applications. I think I would definitely jump on something like that.
You mean like BOB's like the one for the one-wire ATSHA204? I could see that... Honestly, what I do is I have a SOIC-8 socket that I pop these chips in and out for testing. Also, I've use SparkFun's SOIC-8 BOB and these chips fit nicely on them (go figure ;) ).
Where I've like the shield form-factor is that I'll have two dev boards, an UNO and a SAMA5D3 for example, and I can run some stuff with the linux driver on the SAM and then pop it over to the UNO. So, having the same form factor in those cases seems convenient.
But yeah, smaller and cheaper is always better :)
Valid point about software too. I like this uECC implementation. However, on an AVR, it's much slower so there are some cases where the chip does help a bit.
Sorry, little slow catching on to what you were referring to.
I did find something these searching for ATAES132 and believe I could do what you're saying and just create my own breakout boards. Thanks for the tip!
One for ATAES132, one for ATECC108, a BOB for this, a BOB for that...yes, just like you guys have for the ATSHA204.
Or even better, how about a grab bag? :)
Spot on. And thanks for the like to uECC! I started implementing finite clock fields and clock crypto in C# but this is nice too :)
I find the cliche/canned "don't implement crypto yourself because you'll make mistakes" response to be exactly the opposite reason for not implementing crypto yourself. I would trust an implementor who after a thousand attempts finally gets it right (i.e. Edison), more than I would trust an implementor that just takes what he/she was given and runs with it without doing their homework. After all, if it's in NIST's recommendation, we should just go with it, right?
There is great value in learning the inner workings of algorithms and technology, and the reward comes when we finally managed to do it ourselves. After all, isn't that what we're doing with prototyping, learning to do from scratch what's already been done for us at a higher level?
I know the number 1 rule of crypto is "don't make your own algorithm", isn't the second rule "don't implement crypto yourself" because you'll make mistakes?
Making your own algorithm is fine, as long as you know what you're doing. Cryptography is an sophisticated art, which you can't master without a long study of number theory. Actually, rule one is: "Don't rely on the algorithm being secret." The algorithm should be open, the secrecy should be in the key alone.