Re: Encryption of messages between embedded system and PC?
- From: Don <none@given>
- Date: Mon, 23 Oct 2006 13:09:11 -0700
Vladimir Vassilevsky wrote:
David R Brooks wrote:
The smartcard people have put a lot of effort into defending against just this: an attacker with unlimited physical access to several copies of the product, & free to destroy them in searching. You usually can't just probe the smartcard chips.
Your second threat (suborned employees) is much more serious, indeed. Defences may include breaking the secret key/s into segments, with no one department having access to all of them. Of course, the administration cost goes up.
My experience tells me that the desire to include the incredible amount of the enciphering protection into a system is usually either the result of paranoia, ignorance or the overvalued self esteem. Any on those conditions do not contribute to the quality of the product.
Exactly. It increases *your* effort (as the developer) and
steals resources (time, money) from making a better/cheaper/etc.
product. A determined attacker will find a way of "breaking"
(stealing?) any of these protections.
The occasions where the encryption is really required are special and rare.
Actually, not really. Almost anything financial benefits from
good security (transactions at CC readers, ATM's, slot machines,
etc.). And, anything *medical* (privacy issues).
Increasingly, these two categories alone represent a *lot* of
applications! :<
And, with more and more businessware being outsourced to third
parties, those transactions often require protection (e.g.,
"corporate technology/trade secrets/processes/etc." are as
valuable as cash in many industries). But, that can often
be done via more sophisticated gateways than on the embedded
devices themselves.
As for the task described, there is no point to do any strong encryption since the PC software part can be easily analyzed and hacked.
An elegant way to make a lamer proof obscure protocol is to multiply the stream of the data by a polynomial in GF(2) on the transmit side and to divide on the receive side. No synchronization or secret keys are required.
I'd take the opposite approach -- *publish* the protocol.
Perhaps this will be of benefit to some of your customers.
It undoubtedly isn't very sophisticated so you're not
really "giving" your competitor much (in terms of saving him
time/money to reverse engineer it).
And, you may get some goodwill from your customers in the process!
E.g., in manufacturing environments, often the engineers on the floor
have to tweek COTS boxes to do what they *really* want (instead of
what they were *designed* to do). Having access to the protocol
can simplify their cobbling together your devices with other
aspects of their "system".
.
- References:
- Encryption of messages between embedded system and PC?
- From: ElderUberGeek
- Re: Encryption of messages between embedded system and PC?
- From: Paul Keinanen
- Re: Encryption of messages between embedded system and PC?
- From: Don
- Re: Encryption of messages between embedded system and PC?
- From: Steve Calfee
- Re: Encryption of messages between embedded system and PC?
- From: Don
- Re: Encryption of messages between embedded system and PC?
- From: David R Brooks
- Re: Encryption of messages between embedded system and PC?
- From: Vladimir Vassilevsky
- Encryption of messages between embedded system and PC?
- Prev by Date: Re: Program for PCB/Circuit Design
- Next by Date: Re: Providing a clock with an MCU
- Previous by thread: Re: Encryption of messages between embedded system and PC?
- Next by thread: Re: Encryption of messages between embedded system and PC?
- Index(es):
Relevant Pages
|