LibTomCrypt on Teensy 3.0/3.1

Status
Not open for further replies.
Experimentalist

Experimentalist

Well-known member
Hi

Can anyone with some proper programming skills offer advice on how to add LibTomCrypt as a library in Arduino for use on the Teensy 3.0/3.1?

It may be quite heavy weight (micro world) but I would like to do some testing with it and learn more about the crypto tools within.

Anyone?

Ex.
 
I'd narrow your goals to one or two encryption methods. I chose AES 128/CCM with the block truncation option, and a message integrity check (MIC) of 8 bytes. An 8 byte nonce based in part on the packet sequence number.

The block truncation option is important for small packet mediums like 802.15.4 or blutooth. An AES128 encrypted packet as above might have a 16 byte unencrypted prefix in the user payload, where the prefix has the sequence number, destination address, message ID, protocol revision. The encrypted part of the packet would be the user sensitive data. The end of the packet is the MIC. This can fit into a 100 byte packet as used by lots of low cost telemetry wireless radios.

That long list of protocols in LibTomCrypt has a lot of too goofy/proprietary protocols in my opinion. AES128 and for larger packets, AES256 are good standard choices. Lots of code out there to draw upon.
 
Steve, sorry for the slow response and thanks for the info, yet more reading is in order it would seem :0)

Do you have any code you can share?
 
Ah Google...
http://avrcryptolib.das-labor.org/trac/wiki/AES

Lots of others out there.
Be sure to read post #2 here as you make a careful decision on which flavor of AES to choose.
If it's wireless, WiFi of course has this, as does IEEE 802.15.4, and most HopeRF sub-GHz modules, like the RFM69 has AES built-in.
For mass storage, I'd think there'd be something you can reuse.
 
Last edited:
So, I have been reading, and my understanding is thus:

Step1:
I use AES 128, or another 128 bit block cipher, with an IV of all zeros and apply that cipher in CBC mode to create my CBC-MAC, which is commonly known as my tag, t.​

Step2:
I then encrypt my tag, t, with my block cipher in CTR mode.​

Step3:
I then encrypt my message, m, with my block cipher in CTR mode.​

If I understand correctly the output of steps 2 & 3 is what I transmit to wherever.

What I am struggling to understand is how many different keys I need?

As I read it I can use the same key for the CTR mode operations for both the encryption of the tag and the message; provided the counter used never collides with the IV used for the creation of the CBC-MAC, therefore as long as the counter is never all zeros for the CTR operations.

So what I am struggling with is the following.

1. Can I use one key throughout or do I need two, one for CBC-MAC and the other for CTR operations?
2. Can I use the same nonce and counter combination for both CTR operations or must they be different?
3. Have I just misunderstood it all?

Hope you can help untangle my head :0)

Thanks
Ex.
 
I can't recall how CTR works. I remember using AES128/CCM with truncation of the final block. This was needed because the max user payload in the packet was 100 bytes, and we didn't want to have any padding bytes.

I used it with a unique key per end device X communicating with access device A. When a different X was commissioned to work with the same A, a different key was used. And if X needed to communicate with access device A', yet another key was used. (no shared key). This was done to avoid the situation where there are very many end devices X, X', X'', X''' and so on. If the key is compromised to any X, the others are not compromised. With shared key one would have to re-key all X's and at a scale of thousands, this isn't practical.

Also, only the end point in a network can decrypt - routers, switches, bridges would not. This allows untrusted networks to be used. No device in the path from X to A need be trusted. Lack of end to end
encryption is a weak point in many machine to machine systems. An access device that decrypts then re-encrypts for the next hop means the access device has the key for two hops and that's too risky.

Over the air/remote re-keying - best done with a special rekeying key. Rarely used. Message ID implies the need to use the rekey key.
Hardest part is keeping the message sequence numbers, part of the nonce, in sync.

Machine to machine with end-to-end, and not with the complexity of PKI and certificates, for small embedded systems with small packet communications is the theme in this.
 
Thanks for your help, I have been reading the NIST document on the security of CTR + CBC-MAC. Some heavy reading with a tired head but I am sure it will lead to the answers I need for my implementation.

I have two encryption requirements, neither as complex as that you describe. I want to encrypt the communication between the PC and my T3/T3.1 and also the data the T3/T3.1 is storing in files on the attached SD card. I have written my own protocol for the communications between the PC and T3 and will just be encrypting the data section of the message. I am yet to decide on an error correction scheme, that is CRC or similar before encrypting or after. I think I will also get pointers by the end of the NIST document for this.
 
Is the PC to T3, and T3 to T3 link wired? If so, I wouldn't bother with encryption.
If wireless, and you want low cost, non-WiFi, then you might use plug-and-play
http://www.airspayce.com/mikem/arduino/RadioHead/
for the protocols with error correction. I use it on both wired (serial) and on wireless, RFM69 radios. Those radios have on-board AES128. There's a T3 add-on card for them; I use that, and also use the protocols on AVRs.
 
I only have one T3 connected to the PC via USB. I am working on a possible commercial product and I don't want anyone to be able to see the traffic by watching the USB. I am transferring sensitive data from the PC to the T3 including data from a PC side password database. I want to avoid the possibility of those passwords being exposed by another program monitoring USB traffic.

Thanks for the tips
 
Would the attacker be able to run something like Ida Pro on the PC software? If you were planning on embedding keys in your PC executable, how were you planning to protect them? This might be an easier attack than using Bus Pirate or some other USB logic analyzer.

The Freescale Kinetis MCUs in the T3 and T3.1 do have some "lock" bits for disabling readback of the contents of the flash. I haven't heard of anyone defeating this mechanism, but I also haven't heard any strong security claims made about it either. Would it stand up to a clock glitching attack? Would it stand up to a differential power analysis attack?

We're all rushing headlong to create "The Internet of Insecure ThingsTM." :eek:
 
Ultimately, as usual, it is more interesting to ponder these things than watch British television :0)

My possible commercial product will almost certainly only benefit from one customer, myself, but he is very picky. As ever your response just leads me to read even more and learn even more, call it my crossword of sorts.

My current mechanism for creating a secret key is to load the EEPROM with random numbers and then use an algorithm to generate a 16 byte key from the EEPROM based on a PIN entered by the user. The PIN can be of any length, making it slightly harder to crack I suppose, and is entered at the PC end via a keypad, soon to be touch screen or touch pad. If the user gets the PIN wrong the EEPROM is wiped and the SD card contents are rendered useless.

To exchange a key with the PC the plan is to send the EEPROM contents and then get the PC user to enter the PIN from a secure desktop, same PIN, same algorithm, same key.

I am sure it has many issues but whilst it is my toy I challenge anyone to crack it as I make it up as I go along day by day, commercially viable I think it is not at present.

I don't even know what a
pictographer said:
clock glitching attack
Click to expand...
is until I finish writing this :0)

I was interested in the
pictographer said:
"lock" bits
Click to expand...
if you have any further info?

One other thought was that early versions of Teensyduino used to wipe the EEPROM when a new sketch was loaded. It was a pain at the time but now if someone steals my device it could come in handy. That is, anyone who knows it is a Teensy could just write a simple sketch to dump the EEPROM contents and the set a graphics GPU about cracking the cipher based on the contents of this post ;0(
 
Ha! I've got a picky customer like that, too.

Re: lock bits are something on Paul's future feature list. Here is a Freescale Kinetis security application note (pdf).

A big challenge is making your pin long enough that if someone steals your device and manages to dump (extract) EEPROM a brute force attack still isn't feasible while still making the device practical for your use. I've been thinking about this problem for a while. Seems to me that if the pin/password/device key must be entered manually and you don't have a full keyboard, it's going to be tough. On the other hand, if the device has a sensor of some sort, perhaps the key material can come from exposing the sensor to a more-or-less controlled stimulus followed by some error correction so you get the same signal every time.

I've had a few ideas for keying. Suppose the device had one or more photodiodes. To key it, you'd play an animation or movie clip on your cell phone or PC with the sensors carefully positioned in one of many possible positions. You'd need to remember the clip and the position. The actual key length could be reassuringly large.
 
Last edited:
Some interesting thoughts. As I said in early versions of T3 if you uploaded code the EEPROM WAS wiped. This could be used as a security measure to stop the ability to upload a simple sketch that dumps the contents? As you said in another thread
pictographer said:
Has anyone succeeded in dumping the flash of a MK20DX128 or MK20DX256 that's configured not to allow that?
Click to expand...

That thread and this follow my thoughts about this very topic of how to secure a standalone device with encrypted data on a SD card. As you can see I still have not cracked it.

Smart card?
 
Status
Not open for further replies.
Back
Top