Flutter and Cryptography - AES-256 or ECC?

[taylor]

Hey everyone!

One of the remaining questions I have for Flutter is the type of encryption that would be best. We originally planned on using the ATSHA-204 chip from Atmel, but they now have two drop-in replacements that look interesting. I am not by any means an expert on cryptography so I wanted to get community input on what might be the best choice.

One replacement for the ATSHA204 is the ATAES132. That chip has the same features as the SHA204 but includes an AES accelerator. So that one is our default choice for production.

There's another drop in chip that looks interesting, however, called the ATECC108. it uses Elliptic curve cryptography (ECC).

Unfortunately, I don't know enough about crypto to determine if the ECC chip would be suitable for this application and if it would be an improvement. I'm inclined to take the safe route and go with the AES chip, but I know that AES is increasingly seen as less secure than we'd like. Unfortunately I also recall something about a portion of ECC being backdoored.

The ECC chip (in the UDFN I2C variant) isn't really in stock anywhere and seems to be a bit more expensive, so we may not really have a choice. I wasn't too serious about the ECC chip until I saw that Arduino is planning on using it in their new Wifi Shield.

Can we use the ECC chip? Would we want to? I want to have one encryption key per network. The devices have room for 16 keys so the idea is that each device can be part of multiple secure networks. I believe ECC is asymmetrical encryption and I'm unclear how that will affect this plan.

If you're concerned with someone who isn't super familiar with encryption writing the code for this system, don't be. I'm not writing the crypto algorithms, just encrypting and decrypting data before sending it over the air. All development will be in the open so we can seek the advice of people in the community, and I am very aware that subtle flaws in handling encryption can lead to major errors, so I won't trust anything until it's had thorough community review.

What are your thoughts backers?

[gcondra]

Can you talk a bit more about how the keys are negotiated or preshared? And what ECC mode you're thinking about? AES and something like ECDSA have very different security properties.

Regarding AES being weak- don't worry about that. It's as strong as anything else out there at acceptable key lengths.

Regarding ECC being backdoored- that's dual EC DRBG, which you would presumably not be using here. Obviously anything else could be backdoored as well, but there probably isn't a lot of point in worrying about the unknowable machinations of the powers that be. Better would be to firm up your threat model and go from there.

Happy to help where possible, and doubly happy to do a full security review.

[splk3]

I second support for AES. Very mature, very well supported, and very straightforward to configure key generation/sharing to get proper certifications if/when people use Flutter in commercial products and wish to get NIST/FIPS approval. AES has no known significant weaknesses, and 256-bit will make things very secure for the foreseeable future.

[grymoire]

Looking at the specs of the ECC chip, it has support for asymmetric (public/private) keys using (ECDSA), and storage for certificates. The ECC chip is a superset of the ATSHA204 chip. So it has SHA-256 and HMAC/SHA-256. (message integrity/authentication)

The ATAES132 has support for AES (confidentiality)( and AES-CCM (confidentiality and authenticity).

Both chips have a hardware random number generator.

In short, the ECC chip is great for signing (authentication), and the AES is great for encryption (privacy) but it does have the AES-CCM which is used to authenticate/encrypt.

it seems like the two chips are complimentary in purpose. You cannot encrypt with the ECC chip, and you cannot use PKI with the AES chip.

If you want privacy, you need the AES chip. If you want strong per-device authentication, then you need the ECC chip.
Both can ensure a stranger cannot send bogus messages to your device.

If you use the AES chip, you can provide authentication with pre-distributed keys. The question is - do you need per-device authentication or not. If so, you may have a scalability issue. You need (N*(N-1))/2 keys for N devices i.e. 4 devices->6 keys, 5 devices -> 10 keys.

But you might not need per-device authentication, if you just want to have a single shared key with all devices, then you just need one or perhaps two keys.

And you also need to get these keys installed somehow. A single shared key can be part of the firmware, and frankly this is the simplist implementaiton.

I also think having a AES accelerator would provide longer battery life. Frankly, the AES chip would be MUCH easier to integrate into flutter.

[grymoire]

A followup. Any problem with AES is typically the implementation, especially the modes.

For example, basic AES is AES-ECB (Electronic Cookbook Mode). Repeated messages have the same ciphertext. Fail!

Then there is counter mode (AES-CTR) - which fails if you reuse the counter.

Then there is Cipher Block Chaining (AES-CBC) - which fails if the Initialization Vector is public.

And then there is padding which fails if you can distinquish between a padding failure and an encryption failure (Padding Oracle attack).

All of these are implementation errors, not algorithm errors. Expect that the crypto stuff will evolve in quality over time.

And then there are OTA key update issues.

[grymoire]

Looking deeper into the AES chip, I see it has:

1. Storage for 16 keys
2. Using AES-CCM for read/write access of the EEPROM
3. Key management/key update
4. A transport key creating during the manufacturing process
5. Using the device serial number for a device-specific key used for encryption.

In short there is a lot of capability here, and one of the reasons the flutter appealed to me was the ability to experiment with the hardware-based encryption. I'd like to experiment with it and learn more about it.

[gcondra]

Unless there's somebody actually planning to go through the FIPS process with a flutter I'd suggest taking that off the table. It's a huge endeavor and you pretty much have to stop development after its done unless you want to go through the whole thing again.

[gcondra]

+1 regarding "complimentary in purpose".

Typically the usage for public key systems is to use your PKI to share a symmetric key, then use the more performant symmetric cipher for the rest.

I'd still like to know more about what these are going to be used for though. That's the thing that really decides whether you can get away with just one, and which one it would have to be.

[grymoire]

BTW, the AES is only 128-bit. And I agree with gcondra that FIPS-140-2 certification is not a concern. Although I seem to recall that the main requirement for level 1 certification is having a crypto module that uses approved algorithms. But doesn't it require the crypto module to be certified? I don't see it in the specs.

[splk3]

There are several FIPS certs that can be applied for - 197 is another that is more straightforward and basically just says that the AES implementation is to spec. Of course, to get FIPS approval at any level, a vendor need to put up the funds to get the cryptographic core tested and put together the documentation package. Although not likely that anyone will pursue this with Flutter, it is nice to know that we will be able to get a similar amount of trust in the communications even without formal certification

Thanks for the update on 128-bit - still not sure why the accelerator chips are still using 128 instead of 256 - the difference in hardware and performance are negligible. I was working on implementing 256-bit with software on top of the 128-bit acceleration chips while I was in college but that was 10 years ago and I mistakenly assumed that the standard for those was 256-bit nowadays.

I don't see a reason to pay more for ECC when AES is the de-facto standard and will meet any requirements for almost any application of the boards.

[taylor]

Wow, you guys are awesome - thanks for all the detailed information! I had a feeling that the AES chip would be better suited to this task, so thanks for making that really clear.

Interestingly, the CC1200 radio also has an AES-128 accelerator. Since I committed originally to the SHA204 with 256 bit keys, I figured I would keep the crypto chip but upgrade to the AES132 chip with built in acceleration. That was before I noticed that the CC1200 has its own accelerator (something the original CC1100 prototype radio didn't have).

I wonder now, is there much of an advantage of going with the dedicated chip at all besides more secure storage? The board's CPU has a good RNG I believe.

Since you guys looked through the datasheets already and clearly have a better understanding of this stuff, can anyone explain what, if any, the benefit of using the ATAES132 would be over just using the CC1200's built in accelerator and storing keys in program memory?

Thank you so much,
Taylor

[hlieberman]

Hi Taylor!

A couple things that are good for you to know, as someone doing this kind of design.

One of the things that a lot of people will look for when building high-security systems is some chip that they can store keys in so that they can't be easily extracted. These chips tend to have on-board crypto co-processors and define a particular algorithm - or algorithms - that they use. After all, it's not much good to have a secure place to store your keys if you have to hand them back to the main processor for use!

The advantage of the ATAES132, in my opinion, is that it can offload the encryption operations totally without the user having to worry about storing keys securely in memory. As recent events have shown, key handling is an extremely delicate problem with dire consequences for small failures.

The AES accellerator in the CC1200 does have the ability to do in-line encryption, which is nice, but it lacks the ability to append a MAC - message authentication code - to the data. That's a downside, since you wouldn't be able to authenticate the source of the encrypted data. That would mean, in theory, an attacker would be able to cause errors in the underlying message by flipping bits in the ciphertext.

For me, it would come down to what we want Flutter to be for. The ATAES132 certainly isn't going to /hurt/, though it might provide a false sense of security in some situations. Using the main processor for all the crypto is doable as well, though it has implementation concerns for high-security applications, and it will probably use a bit of energy. On the other hand, it's got maximum flexibility - no silicon to restrict you to one algorithm or the other.

Hope that helps!

[Aspenforest]

SHA, AES, and ECC are used for fundamentally different purposes.
SHA is a hash algorithm, which is used to check the integrity of data.
AES is used for symmetric encryption of data, meaning that the same key is used for encryption and decryption.
ECC on the other hand is used for asymmetric encryption, where public (published) key is used to encrypt data and its derivative private (secret) key is used to decrypt data.

Before choosing the chip, you must beforehand determine what do you need the cryptography for.
While you do encrypt data before sending it over air, how are you going to securely perform the key exchange so
that no third party is able to listen in and obtain the secret key used for the data encryption?

In the case of wireless, and even so more regarding Flutter due to its very long range, you need secure communication and authentication between devices to prevent man-in-the-middle attacks and device impersonation.

The safest way to achieve this is to use asymmetric key exchange algorithms such as elliptic curve cryptography or RSA.
With this method, Alice publishes her public key to Bob and then Bob is able to send a secure message to Alice which only Alice can read.
Furthermore, ECC or RSA can be used for authentication, where the private key is published instead.
This can be used in conjunction with the secure key exchange method to ensure security and authenticity.

After a secure channel has been established between two parties by the use of asymmetric encryption, the devices can agree on a symmetric key and then drop to AES communication. The initial exchange of keys needs to be asymmetric.

All together, I recommend using the ECC chip to provide secure key exchange and in-transit encryption and authentication of data.

EDIT: If you unload crypto functions to the main processor, you are going to have frequency hopping sync and other issues, since crypto can be computationally intensive. Thus, it is best to have a dedicated processor for crypto.

[grymoire]

Harlan makes some good points. AES "acceleration" is a vague term. AES can be implemented on an 8-bit microprocessor - it's that simple. So anything than makes this faster is "an accelrator". Which is faster - the CC1120 or the ATAES132? Which one uses less battery? That's not clear - if we had some development boards and wrote some code to test the timing, we would know better. But the accelation/battery usage is only part of the story.

You have to really understand that the keys have to be protected always - either during use, or at rest. Passing a key between chips in cleartext exposes the keys (just use a logic analyzer). So you would ideally want to pass the encrypted message into the AES chip, and let it decode it, and output out the cleartext - without ever sending the key to the AES chip during "typical use". You could tell the AES chip which of the 16 keys to use, but that's it.

Installing the (initial) keys could be something done once. It's sometimes called "provisioning the device". But once this is done, you would like to protect the device.

That may be one use of the crypto-system. But I don't want the flutter to be limited to that single scenario. The openness and flexibility is important. I, for one, would be interested in using the flutter during a security audit, using it as a "packet sniffer" to capture raw (perhaps 6LoWPAN) traffic, and then try to see if I can determine the key. That is, I'd like to set up two flutters to secretly communicate, and then use a third one to "sniff" the raw data and see if I can crack it. Once I do that, I'd try it against other 900Mhz devices.

I don't expect Taylor to provide all of the code, BTW. I expect a group effort as we find the best way we can make the Flutter be flexible and secure. With a good plaform and an open environment, I hope we all can contribute and improve it.

[Aspenforest]

With a properly implemented asymmetric key exchange algorithm,
you will have zero chance of cracking any data you might have obtained from 3rd party Flutter networks.
This is also why I strongly suggest choosing the ECC chip instead of the SHA or AES ones.
Malicious entities will be otherwise able to crack flutter networks, and we don't really want that, right?

[hlieberman]

With respect, Aspenforest, I think it's disingenuous to say that there is a zero chance from cracking a Flutter network, no matter what chips, algorithms or protocols that we use. In fact, I would argue that the certainty of us making an error that will allow for a compromise of a Flutter network approaches definite, once you consider the amount of unwritten, untested code that will need to be released to support doing so. Many of the best software companies in the world have applied their efforts to defending their systems against such compromises, but as SSL/TLS has shown us, that is a high bar to match.

Do I think that ECC would, perhaps, be a better choice for asymmetric negotiation than its more traditional counterparts of RSA or DH? Yes, because the reduced message sizes makes transmission easier. On the other hand, given the /likely/ deployment mechanisms of Flutter and the high power and compute restraints, limiting ourselves to symmetric algorithms seems a logical step.

In any regard, the ECC chip proposed appears to be for signatures anyway, and not with a protocol that I personally would recommend, so academic debate aside, there's no question in my mind for the advantage of the ATAES132 over the ATAECC108. The question about whether such a chip is needed is, in my mind, still an open question.

[grymoire]

With a properly implemented asymmetric key exchange algorithm,
you will have zero chance of cracking any data you might have obtained from 3rd party Flutter networks.

I don't see how the ECC chip can do that. As far as I can tell, it does not do encryption.

[grymoire]

The question about whether [ the AES chip] is needed is, in my mind, still an open question.

I don't have personal experience, but I think the AES chip allows you to encrypt/decrypt information without storing the key in cleartext on the main CPU, which in turn is extractable to anyone with a JTAG debugger (e.g. GoodFET.)

It may also provide a longer battery life if the comunication is encrypted.

[hlieberman]

I think the AES chip allows you to encrypt/decrypt information without storing the key in cleartext on the main CPU

That's my reading of the datasheet as well. It does mean, though, that we are limited to AES-128 in CCM mode - not the end of the world, for most applications, though it is a bit less efficient than some alternatives that could have been chosen. It is still very possible, if not probable, that it's still more efficient than either using the accelerator on the radio chip or on the main chip itself, as well as having other desirable security properties.

[Aspenforest]

My apologies, you are right.
I did not notice that the first time I looked at (skimmed) the documentation of the said chip.

Usually, it would make sense to make asymmetric ciphers usable two ways,
for encryption and for authentication, but for some reason, Atmel has opted to
not implement the former option (perhaps because correctly implemented
ECC is a bitch to crack for NSA?)

In any way, Taylor is able to implement an asymmetric key exchange algorithm
in the C code which runs Flutter.
In this case, perhaps it is best to choose the AES chip for comm encryption...