1

I want to monitor an input and then send the information in an encrypted way that can't be easily unlocked even if a malicious actor gets access to the device itself. I'm new to using the Teensy although I have done a few simple things with Arduino microcontrollers. I was hoping to find out if anyone has implemented RSA or other asymmetrical encryption on a Teensy or to figure out if it has enough processing power to make it feasible. I would also accept using other Arduinos (I have an MKR1000 as well), for this but I assume because the Teensy has much better performance it's more likely to be able to do computationally expensive encryption.

This won't need to decrypt anything, it will only be sending data encrypted using the public key of the receiving user.

joel_xay
  • 11
  • 2
  • Your question can not be fully answered, because we don't know how many bytes per second you intend to encrypt. You should already be aware that asym. encryption methods like RSA only exchange symetric keys with asymetric technology. The pyload is en-/decrypted synchronous. If the hacker get's access to your device, the security depends on whether you have secured the private key with a password, and how secure the password is. 100% security is impossible. The internet is full of infos on teensy encryption, e.g.: https://forum.pjrc.com/threads/24327-RSA-encryption – Peter Paul Kiefer Dec 26 '20 at 10:38
  • I'm not able to access that site due to my VPN and archive.is appears to have the same issue. Can you share the relevant information here? I don't expect a black and white yes/no answer, I would accept info on encryption methods and/or how many bytes per second RSA encryption a Teensy is likely to be capable of. – joel_xay Dec 26 '20 at 11:37
  • I have not given you an answer you can accept. I just mentioned, that you give us too few information to answer the question "Is the teensy fast enough" and I pointed you to an page where the usage of an RSA lib is explained. Please do not excpect me to write a complete program or library you can use, I have neither the time nor the intention to do so in my rare spare time. If you can access SO pages, why can't you access ordinary internet pages? – Peter Paul Kiefer Dec 26 '20 at 11:44
  • The site you've linked has blocked my VPN or IP addresses from my country, it seems. I am sorry. I would also be very surprised if anyone went to the trouble to write a library as a response to this question. Maybe I was unclear in wording, I meant I would accept answers that explain how to determine the speed of the encryption on the Teensy. – joel_xay Dec 26 '20 at 11:52
  • I'm sorry too, if it looked like I tried to offend or attack you. That was not my intention. The best way to determine the speed of an crypt method is to use some libs and check wheter it works and how many through put one can archieve. The speed and RAM consumption heavily depends on the algorithm that is used. So asynchronous encryption is very time consuming, but as I mentioned, it is mainly used to encrypt synchrounous keys. And synchronous en-/decryption is much more performant. But without having to chance to download a lib, I fear you have no chance to try out something. – Peter Paul Kiefer Dec 26 '20 at 12:17
  • A Hint: Try the following keywords in a search engine: RSA, Teensy, Relic. Probably you have access to the Relic project on GIT hub . https://github.com/relic-toolkit/relic . Here is an older page: https://code.google.com/archive/p/relic-toolkit/ – Peter Paul Kiefer Dec 26 '20 at 12:19
  • I'm a bit confused about your use of the word asynchronous. I'm not very familiar with cryptography so I don't know anything about synchronous vs asynchronous encryption, this isn't terminology I've heard used for encryption before. Did you mean asymmetric or is synchronicity something I need to look into? – joel_xay Dec 26 '20 at 12:20
  • @PeterPaulKiefer thank you for linking the relic toolkit. I will investigate. I'm concerned about the disclaimer on it "RELIC is at most alpha-quality software. Implementations may not be correct or secure and may include patented algorithms. There are many configuration options which make the library horribly insecure." I guess I assumed there would be something PGP-like out there for Arduinos... maybe it doesn't exist? – joel_xay Dec 26 '20 at 12:25
  • I fear you can not write a really good encryption for your project, if you do not learn how encryption works. That's nothing one can teach you here. Check the internet for information on synchronous, asynchronous, encryption, RSA, DSA, Diffie Hellmann, Public key, Private Key. Then you understand the issue with the relic toolkit better and can decide if it is useful. – Peter Paul Kiefer Dec 26 '20 at 12:34
  • Synchronous encryption means you have only one key both endpoint must know. This key is used to encrypt and to decrypt a payload. The synchrounous methods are very performant compared to the asynchronous methods. Asynchrounous means you have two keys a public and a private key. You send the public key to the communication partner which uses it to encrypt a payload and then sends the encrypted payload to you. Only the private key can be used to decrypt the payload, but the public key can not be used for decryption. – Peter Paul Kiefer Dec 26 '20 at 12:38
  • I think we need to back up here and look at the big picture. You say you want a system that can't easily be unlocked even if an assailant has the hardware itself. But then he'd have access to the raw sensor output directly, and wouldn't even need to worry about any encryption. Is there something I'm missing here? – Boggyman Dec 26 '20 at 13:54
  • @Boggyman An attacker would naturally have raw sensor data from the point of getting control of the system onward. But I would like for the attacker to not be able to decrypt data that was sent prior to obtaining the hardware, even if the attacker had somehow recorded it. – joel_xay Dec 26 '20 at 14:10

1 Answers1

1

Teensy4.1 has 55 digital IO (serial) pins at up to 200MHz. The USB port supports 480mbps, and ethernet is 10/100mbps. You're limited to 32 DMA channels, though (complicated but these are used to access onboard peripherals/memory). You don't have much contiguous ram, either.

Now, you haven't explained what you're doing with this data. This matters because even though the CPU is running at 600MHz, asymmetric encryption is slow. Are you trying to perform real-time encrypted communication? Are you just sending or receiving data as well?

Nothing stopping you from asymmetrically encrypting on a Teensy. You can find the source code for the OpenSSL functions RSA_public_encrypt and RSA_private_decrypt. This question goes into calculating how many CPU cycles are needed to encrypt X bytes of data.

However, asymmetric encryption has problems: Like I said, it's slow - specifically RSA, and the size of the data you can encrypt depends on the size of your key and padding.

If you want to communicate in something resembling real-time, you want to use hybrid encryption. You should read about how TLS works; the short version is that an asymmetric handshake occurs where the two parties agree on a symmetric key. Once you decide what your data actually is, you can quantize it (eg. TLS 'chunks' are up to 16KB which are then sent as multiple TCP packets) then both parties use the symmetric key to send/receive - which can encrypt large data chunks without issue.

CSoft
  • 33
  • 4