More on SCADA comm security

Further to my last (hopefully this posting is visible amongst all
the sporge).

The concern is that in my client's current product, RF communications
with the RTU's are in plaintext visible to anyone with a capable
receiver.

The Master Station is a hand-held device with a cell modem
and a proprietary RF transceiver to connect with the RTU's. It does
use a secure shell for Host messages. RF security has not been an issue
because it's extremely unlikely for an evesdropper to be nearby
(within 100 meters) with just the right snooping equipment when
a technician happens to be there servicing an installation.

However, by its nature the objective of this project creates a greater
security risk; it's to reduce the expense of personnel routinely
patrolling the coverage areas; only emergency situations would need
human intervention.

To achieve this the hand-held units are to be replaced with
network-accessed Master Stations installed in fixed locations with
difficult physical access. The RTU's cannot be protected so well however
and an intruder could operate unobserved.

My client believes that the threat of RTU tampering is still low,
but considering the liability issues wants some minimal security
protection for the RF signals, at least for marketing purposes.

The worst threat scenario is that the attacker steals an RTU.
The hardware designer will include some tamper detection, but we could
only detect the theft, not prevent it.

Once in possession of the RTU, the intruder breaks into its enclosure,
chips away the potting and extracts the transceiver, giving him
access to the cyphertext of legitimate message traffic. He also has
the RTU's main circuit board to experiment with faked messages.

After listening to enough traffic to break the security scheme,
the worst case is that he causes unauthorized actuations, with serious
results. This could be considered far-fetched, except that similar
tampering with remote telemetry control has actually happened.

There are several factors in our favor, however. One is that actuations
are rare. Most messages consist of a status poll and response and only
a seriously dedicated saboteur would have the determination to maintain
long enough surveillance to correlate an actuation command with
the action.

I suppose no scheme within our reach would be effective against anyone
with enough skills and intent. There are easier ways to wreck havoc,
and there is much better monetary payoff for a thief to prowl around
parking lots eavesdropping on Keeloq signals than to target our system.

I'm not sure what's worse, well-funded foreign terrorists, bored
teenagers with enough technical savvy to be dangerous or some one in
a million lunatic with an unshakable obsession (and a Ph.D in math).

So do we need encryption at all? My client is not comfortable sending
the RF messages in the clear, but I'm not sure how to implement anything
even approaching industry standard security on a tiny microcontroller
without (for cost reasons) any supporting hardware such as code-hopping.

I suppose whatever I come up with will be more of a marketing feature
than anything really effective and the Marketing Dept can conjure up
for the customer some shadowy Boogey-man which only our
state-of-the-art-secret-proprietary-not-subject-to-peer-review system
can stop.

Comments invited;
TIA, Sean_Q_
ps. For a small scale security model LFSR's could be sequenced by
the main tick interrupt, 100 msec or so, but slightly different for
each unit.

A 32-bit word with well chosen taps would ensure a reasonably long
pseudo-random sequence and RF commands to initiate a session would
arrive at asynchronous points in the sequence, providing some entropy
for key exchange/authentication.

The public key could be the unit's serial number. The messaging model
is mostly poll-and-response, unless the RTU detects a tamper, where
it sends an immediate alert to the Master Station.

In operation, routine network commands resulting in RF sessions
are fairly infrequent, making them harder to penetrate.

There is a Technical Specification from IEC (IEC/TS 62351) that may help 
you:

http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=sea22.p&search=iecnumber&header=IEC&pubno=62351&part=&se=&submit=Submit

Sean wrote:
> Further to my last (hopefully this posting is visible amongst all
> the sporge).
> 
> The concern is that in my client's current product, RF communications
> with the RTU's are in plaintext visible to anyone with a capable
> receiver.
> 
> The Master Station is a hand-held device with a cell modem
> and a proprietary RF transceiver to connect with the RTU's. It does
> use a secure shell for Host messages. RF security has not been an issue
> because it's extremely unlikely for an evesdropper to be nearby
> (within 100 meters) with just the right snooping equipment when
> a technician happens to be there servicing an installation.
> 
> However, by its nature the objective of this project creates a greater
> security risk; it's to reduce the expense of personnel routinely
> patrolling the coverage areas; only emergency situations would need
> human intervention.
> 
> To achieve this the hand-held units are to be replaced with
> network-accessed Master Stations installed in fixed locations with
> difficult physical access. The RTU's cannot be protected so well however
> and an intruder could operate unobserved.
> 
> My client believes that the threat of RTU tampering is still low,
> but considering the liability issues wants some minimal security
> protection for the RF signals, at least for marketing purposes.
> 
> The worst threat scenario is that the attacker steals an RTU.
> The hardware designer will include some tamper detection, but we could
> only detect the theft, not prevent it.
> 
> Once in possession of the RTU, the intruder breaks into its enclosure,
> chips away the potting and extracts the transceiver, giving him
> access to the cyphertext of legitimate message traffic. He also has
> the RTU's main circuit board to experiment with faked messages.
> 
> After listening to enough traffic to break the security scheme,
> the worst case is that he causes unauthorized actuations, with serious
> results. This could be considered far-fetched, except that similar
> tampering with remote telemetry control has actually happened.
> 
> There are several factors in our favor, however. One is that actuations
> are rare. Most messages consist of a status poll and response and only
> a seriously dedicated saboteur would have the determination to maintain
> long enough surveillance to correlate an actuation command with
> the action.
> 
> I suppose no scheme within our reach would be effective against anyone
> with enough skills and intent. There are easier ways to wreck havoc,
> and there is much better monetary payoff for a thief to prowl around
> parking lots eavesdropping on Keeloq signals than to target our system.
> 
> I'm not sure what's worse, well-funded foreign terrorists, bored
> teenagers with enough technical savvy to be dangerous or some one in
> a million lunatic with an unshakable obsession (and a Ph.D in math).
> 
> So do we need encryption at all? My client is not comfortable sending
> the RF messages in the clear, but I'm not sure how to implement anything
> even approaching industry standard security on a tiny microcontroller
> without (for cost reasons) any supporting hardware such as code-hopping.
> 
> I suppose whatever I come up with will be more of a marketing feature
> than anything really effective and the Marketing Dept can conjure up
> for the customer some shadowy Boogey-man which only our
> state-of-the-art-secret-proprietary-not-subject-to-peer-review system
> can stop.
> 
> Comments invited;
> TIA, Sean_Q_
> ps. For a small scale security model LFSR's could be sequenced by
> the main tick interrupt, 100 msec or so, but slightly different for
> each unit.
> 
> A 32-bit word with well chosen taps would ensure a reasonably long
> pseudo-random sequence and RF commands to initiate a session would
> arrive at asynchronous points in the sequence, providing some entropy
> for key exchange/authentication.
> 
> The public key could be the unit's serial number. The messaging model
> is mostly poll-and-response, unless the RTU detects a tamper, where
> it sends an immediate alert to the Master Station.
> 
> In operation, routine network commands resulting in RF sessions
> are fairly infrequent, making them harder to penetrate.

A couple random thoughts...

If you're going to encrypt, use an industry-standard
encryption, not something homespun.  Even the obsolete
DES would probably be adequate given the small amounts
of traffic and relatively small value of the data.

If you homespin the encryption and there's ever a
compromise, somebody is going to have to make a painful
explaination as to why they thought they were an
encryption expert.  Much better to use a standard and
let the customer sign off on its acceptability.

Public/private key is probably overkill.

Hardware tamper switches are good.  Software comm
error counts are also good and will serve somewhat
as a comm "tamper switch".  Likewise, the remotes
can be programmed to refuse incoming commands other
than reporting status if they detect a certain level
of nonsensical requests and commands until they are
reset by a human.

The scenario of an intruder stealing and reverse
engineering the protocol is a bit silly.
If he could penetrate the system that deeply, why
wouldn't he just hotwire the control points while
he's in and be done with it.  It would be a lot
less trouble.  Once the physical security is breached,
there's not much you can do other than send an alarm
and safe as much of the system as you can.