1
$\begingroup$

I work on a project about CAN bus and I want to encrypt the data among nodes but I have have a problem because CAN bus nodes receive and send 8 bytes among each others and I know the size of AES output is exactly the same as the input. I am confused. As far as I knew, AES works in blocks of 16 bytes. My question is :

How can I reduce the output aes size to enable CAN bus nodes receiving 8 bytes correctly (the actual message coming from any node) ?

$\endgroup$
2
3
$\begingroup$

When you're working with this severely constrained environment, it's probably more involved than what you can get from listening to some strangers on stackexchange; you probably either need to follow some existing CAN bus encryption standards (written by an expert), or get a professional developer - the concerns go considerably farther than "how do I use AES"

I will go through some of the obvious issues:

  • What are the security goals? Is it so someone listening in on the CAN bus cannot read the messages? Or, is it just to ensure that any received message is from the authorized sender? For example, is it someone else on the CAN bus cannot insert their own commands, either random commands (DOS attack), selected commands, or reissuing previous valid commands? Is it so someone cannot modify commands in flight (which might be possible, if they can receive the ciphertext, somehow prevent the receiver from getting the original ciphertext, and then reissue a modified ciphertext)?

  • You state that the ciphertext must be 8 bytes - is the corresponding plaintext also 8 bytes? The problem with that is that someone could inject an 8 byte ciphertext, and it'll decrypt to some valid plaintext.

  • Using AES assumes that the sender and receiver share a secret key; is this true? How is the key shared? Is it preprovisioned at the factory or installation time? Or, is it somehow negotiated (and if so, what are the details)?

  • I assume that the sender and receiver are not guaranteed to remain "in sync"; that is, the receiver might miss a valid message from the sender. I also assume that the system needs to be 'best effort'; that is, having the system reject valid messages is intolerable (e.g. you don't want to ignore the brake pedal messages of "I've just been pressed" just because the cryptosystem just got into the wrong state). If this assumption is not true, there are some useful techniques that are possible.

Now, given the likely answers to above, my first instinct for an encryption mode would be to use a format preserving encryption, such as FF1 (which uses AES to encrypt an arbitrary length message, such as 64 bits). However, FF1 is computationally expensive (it uses about 10 AES evaluations to encrypt/decrypt a 64 bit message), and is at best only a small part of the entire solution.

$\endgroup$
0
$\begingroup$

If you use AES as a stream cipher you can use CTR mode and send no more than the message size. However this won't give you message authentication and you need to make sure sender and reciever are in sync. Dealing with such extra requirements will inevitably find you sending more data than the raw message.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.