Re: Encryption of messages between embedded system and PC?
- From: "Le Chaud Lapin" <jaibuduvin@xxxxxxxxx>
- Date: 23 Oct 2006 23:21:33 -0700
ElderUberGeek wrote:
So here is the question. I have found several components (say for .NET)
that will allow you to encrypt strings, files and streams easily. The
thing is, that is nice for the PC side, but what about the embedded
side where I am running some MC (that only understands C...).
Any ideas how to solve this, what a good strategy would be or maybe
even some components that exist?
Warning: Long Post.
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
1. Asymmetric Cipher (you should use RSA)
2. Symmetric Cipher (use Rijndael-128 bits or RC6-128 bits)
3. 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. :)
-Le Chaud Lapin-
.
- References:
- Encryption of messages between embedded system and PC?
- From: ElderUberGeek
- Encryption of messages between embedded system and PC?
- Prev by Date: Re: As a "general rule"?
- Next by Date: Re: Accessing global var of another file
- Previous by thread: Re: Encryption of messages between embedded system and PC?
- Next by thread: OSS or Free RTOS recommendations?
- Index(es):
Relevant Pages
|
