Crypto is easy. Key management is hard. Trivial crypto (essentially rot-13 or something) is not a lot easier than using something real, such as DES or AES-128.
Adding crypto greatly increases the pain of debugging your application.
You need to think hard about what problem you have, and how you expect that your solution will do anything.
The classic example is CSS, the DVD content scrambling system. It used decent crypto, and crappy key management, and was cracked in a trivial amount of time.
For most embedded systems, you are better off publishing your protocol than pretending that you can properly use crypto against a serious attack.
If the attacker has physical access to the components, it is not worth bothering unless you have really hardcore needs. There are special boxes, Harris and others sell them to banks, that do crypto internally, and destroy the keys if you open the box, take smartcards to reset, etc. They are not cheap, and it isn't clear that they provide all that much security. They do provide a lot of theater.
Sometimes the appearance of protection ismore important than delivering any real security. See all the BS at airports...
This is a very common problem with common solutions. What you do, as others have pointed out, depends on how sophisticated you want your protection to be. If performance is not an issue (as it seems with that MC), then you can have your cake and eat it.
Only three primitives are required to protect you from almost any threat. The only thing you have to worry about is the replay attack, which I will discuss in a moment.
You need
Asymmetric Cipher (you should use RSA)
Symmetric Cipher (use Rijndael-128 bits or RC6-128 bits)
Hasher (SHA-256 or SHA-1 are fine, I'd use SHA-256)
If performance is not an issue...give the device a public/private key pair and the PC a public/private key pair. When the PC wants to send data to the device, it would encrypt the data with the public key of the device. The device will decrypt the data with the private key of the device. No other party, not even the PC, can decrypt data encrypted with the public key of the device. When the device wants to send data to the PC, the device encrypts the data with the public key of the PC. No other machine, not even the device, can decrypt data encrypted with the public key of the of the PC. When you look at the intricacies of the RSA symmetric cipher, you will see talk of raising an integer to a power modulo some other integer. This is all true, but sometimes it takes a while for programmers to find out what in their data forms the first integer. The answer is "pieces of each frame sent" - you will have to break your frame into chunks so that each is smarller than the second integer, the modulus N of the RSA algorithm. Encrypt each chunk, send the chunks as a list, and when they are received on the other end, decrypt them, and reassemble them afer decryption by concatenation.
If performance is an issue...use a symmetric cipher with RSA. The public/private key pairs will have to have a modulus whose bit-width is greater than that of the symmetric keys, so if you use Rijndael with
128-bit keys, you could use RSA moduli of 512-bits, though 1024 bits is generally considered the mininum, and some even say 2048 bits now. There is nothing wrong with having a large RSA modulus. To encrypt your frames using a symmetric cipher, you do not have to worry about breaking it up in chunks anymore. Instead, first encrypt the entire frame using the symmetric cipher and the symmetric key of the cipher, and then, *encrypt the symmetric key* with the public key of the target, and append the encrypted symmetric key to the frame. When the target of the frame receives the frame from the source, the target will decrypt the encrypted symmetric key with the private key of the target, then use the decrypted symmetric key to decrypt the data of the frame. Since the symmetric key is typically 128 bits, it will be a lot shorter than the full length of the frame, and will not overload the MC with compute-intensive modular arithmetic. There is no comparison betweens speed of asymmetric encryption versus symmetric encryption - symmetric encryption wins many times over.
But there is still a problem. The source of the frame might not be whom the source purports to be. It is trivial these days for a computer to insert a bogus source IP address into a packet, say, to say that it came from Buckingham Palace, when in fact it comes a shack in Ohio. The target of the frame cannot rely on the source IP to positively identify the source, especially in a wireless situation. The solution to this problem is, again, the asymmetric cipher. Note that it is absolutely positively necessary to combat this problem using asymmetric cryptography. No amount of mathematical trickery will allow you to circumvent this problem using symmetric crypto. That said, what you wold do is the same thing you do in the preceeding paragraph, but just before the source sends the frame to the target, the source computes a hash of the frame using the hasher (any good hasher will do), *and*, encrypt the digest of the hash with the *private* key of the source, then append the encrypted digest to the frame. The target will get the frame, compute the digest of the frame data using the hasher. It will then decrypt the encrypted digest with the public key of the source. If the two digests match, then no one other than the true source could have been the source of the frame, for no one other than the true source could have forged the encrypted digest that matched. Consider...the decrypted digest is some sequence of bytes. It is virtually impossible to generate that sequence arbitrarily using the hash function (this is the whole point of a hash function). Therefore, if anyone wanted to inject a bogus frame, first they would have to make the frame, then compute its digest, then some how encrypt that digest such that, when it is decrypted by the target with the public key of the purported source, it would match the computed digest of the frame. That is too much to ask - only the source knows the private key of the source, and is therefore able to encrypt the digest in such a way that it matches when decrypted, and as mentioned, the data had better be right too, or the decrypted hash will not be what it should. (I hope this makes sense).
There is one last issue which is somewhat difficult to combat. It's called the replay attack. After you have secured your channels using techniques in preceeding paragraph, a frustrated adversary will realize that he cannot forge frames, nor snoop on them, but one thing he can do is capture all communication, encrypted or not. Later, at the most critical moment, he will inject these stalte frames into the channel, hoping to "poke a stick into the spokes of the wheel". The target will get confused, as the stale frames will look valid, even though they are a week old. Unless you build some mechanism that says "Not only must the frames be valid, but they cannot be too old", you will be vulnerable to this problem. The "right" way to combat this is to use time stamps. Time is golden in this situation. You could time stamp each message, and when the target gets it, it would verify that the frame is "not too old." "Not too old" could be a few milliseconds or a few seconds, but obviously, it should not be an hour or a day. This means your clocks would have to be synchronized as best as possible, something that is hard to do. To avoid this problem, you could include a "unique session token" in each frame that is generated by the target and known by the source. The target will keey a set of these session tokens, and if it encounters a frame, within a reasonable time window that contains that session token, then the frame is part of a replay attack and should be discarded. After some time, long enough where clock synchronization doesn't matter, you can dump your session tokens so that they could be used.
Or, if you don't want to do all this, just use a Caesar cipher and pray that your adversary is not very clever. :)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.