Flutter and Cryptography - AES-256 or ECC?

[taylor]

Brilliant discussion, thank you guys for taking the time to explain all this.

So would the ECC chip provide options for more secure key exchange? Do any of these options offer us a possibility of maintaining good physical security? I am interested in making Flutter a viable system for very high security applications like communications amongst freedom fighters against a state actor. At least, if the difference is $0.20 I'd go that way.

It sounds like there are some unknowns with regards to power consumption. I am happy to customize some boards with both chips down the road if a user wanted to do some serious qualification of the performance of either approach.

Without having that information, I am getting the feeling that the ECC chip may offer more security options. Though it also sounds like doing AES in the CPU may interfere with operation? Most timekeeping in the chip is done by a hardware timer. Every millisecond it ticks a variable in software, but that's it. We get sub-millisecond resolution by setting that timer to fire early for one cycle. One of the Arduino modifications is that this timer is now the highest priority instead of the lowest, and the loop is written to avoid anything unnecessary. When it needs to hop frequencies or read data it fires a software interrupt at a lower priority to process things, so the timing loop can keep running.

Does it sound like we would be okay doing AES in software? Or the radio accelerator?

Would the ECC system have a common key between devices? There's only 16 key slots in the crypto chip. Or does that not make sense? I'm still wrapping my head around public/private key systems. I know how they work, but I am still not visualizing the use cases beyond secure email. If you do need individual keys for each device for it to be secure, would this system then be limited to 16 devices in this high security mode?

I need to spend more time looking over all this, but I wanted to chime in on the discussion and say thanks again for all this. This thread is super useful.

[hlieberman]

So would the ECC chip provide options for more secure key exchange?

While the long answer is "sort-of", the short answer is an emphatic "no". The AES chip is far more likely to be useful to someone building a high security application than the ECC chip that you refer to. The ECC ship is really designed for a DRM kind of application - a chip you can use to authenticate a device as genuine, more than something you'd use to build a cryptographic network on top of.

Do any of these options offer us a possibility of maintaining good physical security?

The AES chip will allow for keys that never leave the device, which is pretty much the #1 thing that you are looking for. Personally, I wish that it supported larger keysizes, but I'm not sure there's a drop-in replacement that does. Still, it's certainly better than no chip, and better than the ECC chip.

[Aspenforest]

Yes, hlieberman is correct.
Over-the-air encryption needs to take place on the fly in the discrete AES chip, since it relieves the main processor from computationally intensive cryptographic functions.
However, I do believe that the initial comm channel establishment should begin with a software implemented a-symmetric cipher, and when a channel has been established between two devices, they can drop down to discrete AES for efficiency.
Perhaps you are able to implement both discrete crypto IC-s, the AES and the ECC?
Maybe it is possible to use the ECC chip as an internal security feature, which contains the device ID and provides proof, that the device in use is an authentic Flutter device. Perhaps it is also possible to disable Flutter when the ECC has been tampered with, to prevent third party devices with modified (and potentially malicious) firmware from joining any existing networks. Or perhaps, it might be possible to switch Flutter between two modes: 1) authentic, and 2) modified. Modified devices cannot communicate with authentic devices and vice versa. This is, because to ensure security, all devices must run the same firmware.
One way to do this would be to store the main flutter firmware code in an encrypted format, where the private key resides on the ECC chip, and is used on boot to decrypt the firmware. Encrypted firmware goes into the ECC chip, decrypted firmware comes out. This setup should be secure, if only the ECC chip sees the private key (which you probably have to install in the factory).
Once the firmware has been booted, the device is said to be authentic and verified, since the only way to do that would be to decrypt the firmware with the key provided by the ECC chip.
After the boot, when the device begins scanning frequencies to pair with other devices, the firmware itself should have an additional implementation of an asymmetric key algorithm in its software, which is used to establish a comm channel between devices. Once that has been completed, the firmware unloads the crypto to the AES chip.
It seems to me, that both chips are necessary for a secure Flutter device.