Re: Encryption of messages between embedded system and PC?

Steve Calfee wrote:
On Sun, 15 Oct 2006 10:12:07 -0700, Don <none@given> wrote:

Paul Keinanen wrote:
On 14 Oct 2006 13:34:24 -0700, "ElderUberGeek" <aribloch@xxxxxxxxx>
wrote:

In a common situation such as a PC controlling some embedded unit, some
form of messages is implemented (using serial, TCPIP etc.). Invariably,
it is simply too easy to tap in to that link and reverse engineer the
application protocol. So, the solution (I would think) is to have some
type of encryption on the link to garble the messages and at least make
them very difficult to understand.
While the embedded unit could be a single chip microcontroller and use
the option of preventing external access to the controller, but how
are you going to protect the PC ? Unless the physical access to the PC
can be inhibited, how are you going to prevent the disassembly of the
encryption code in the PC and thus reverse engineering the protocol ?
It depends on what you are trying to protect against as well as
the characteristics of the system in question.

It is possible that the only aspect of the system that is accessible
is the *link*. I.e. uC and PC may be in secure -- or otherwise
inaccessible -- locations. The "link" media may, however, not
have these types of protections (e.g., wireless).

Also, there is a difference between motivations for protection:
- keep competitors/users from "stealing" your product
- keep "observers" from seeing what is happening in the "process"
that you are controlling/whatever
- keep others from *interfering* with the "process" that you
are controlling

The first is hard to do. Anyone sufficiently motivated ($$)
can simply *buy* one of your devices and reverse engineer it
at their leisure -- possibly using destructive techniques.

Not true. If you want to be secure, and do it correctly you can
publish the algorithm, publish the source and still be secure (as long
as you protect the key). Security through obscurity will only work

I think you failed to read my message correctly.
Publish your algorithm. I buy your *device*. Unencapsulate
the components, expose the die and microprobe the *executing*
processor. Now I have a copy of the key, effectively
(even if that may not be in a simple numeric form).

Sounds pie-in-the-sky? Can now be done at many universities
on a student's budget (so, a *corporation* can easily do same!).

Talk to MS about how long their *hardware* secrets survived
in the XBOX...

against lamers. There is a computability price, RSA public key stuff
takes major processing, 3DES and AES not so much. So depending on how
you handle the keys, encryption can be done on some embedded systems.
Most current encryption algoritms have not been cracked and there is
no known way to crack them (in reasonable time frames) with brute
force.

You are ignoring the physical attack on the device itself.
Since you can't control who *buys*/acquires the devices,
you can't prevent someone from reverse engineering the
device itself (this happens a LOT... you are naive if
you think it doesn't).

Depending on the complexity of the device itself (the OP's
application suggests the field nodes are not as capable/complex
as a "PC" so they are probably quite easy to reverse engineer),
a competitor can simply buy one of your *employees*,
clandestinely, and have the design *documents* handed to him
in a manilla envelope :< (given how expensive engineering
*time* is, a determined adversary could gladly spend a
few hundred $K to save a man-year of development effort!)

"Never Say Anything" may be able to crack some publicly available
stuff, but who would know? Reasonable protection against reasonable
foes can be attainable.
.

Relevant Pages

  • Re: Encryption of messages between embedded system and PC?
    ... it is simply too easy to tap in to that link and reverse engineer the ... the option of preventing external access to the controller, ... are you going to protect the PC? ... have restrictions on the use of crypto technology. ...
    (comp.arch.embedded)
  • Re: Encryption of messages between embedded system and PC?
    ... it is simply too easy to tap in to that link and reverse engineer the ... the option of preventing external access to the controller, ... encryption code in the PC and thus reverse engineering the protocol? ... It depends on what you are trying to protect against as well as ...
    (comp.arch.embedded)
  • Re: Encryption of messages between embedded system and PC?
    ... it is simply too easy to tap in to that link and reverse engineer the ... the option of preventing external access to the controller, ... It depends on what you are trying to protect against as well as ... an attacker with unlimited physical access to several copies of the product, & free to destroy them in searching. ...
    (comp.arch.embedded)
  • Re: Shameless Plug
    ... >> In N years of setting up servos, I have never once found a use for ... >rearrange the inputs to an op amp and reverse the sense of a signal. ... on further controller action which might cause unacceptable overshoot. ...
    (sci.electronics.design)
  • Re: .NET Code reverse engineering
    ... L> engineer the .NET code. ... L> The data is highly sensitive, so I'm looking for a suggestion on how to protect ... L> compiled code from reverse engineering. ...
    (microsoft.public.dotnet.distributed_apps)
Loading