Help w small system comm security

Hi, Newbie here...  I am developing a small-scale SCADA system with
Master Stations controlling up to 100 RTU's each, via short range
(100 meters) RF signals. The Master Stations will be connected via
the Internet to a host computer.

We need to secure both the RF and the Internet communications. I am new
to the security issues involved and need a few clues on where to find
techniques for small microcontroller-based systems.

I've found plenty of info on secure shell systems, but they all seem
to involve a formal OS such as Linux, whereas my platforms (Master
Station and RTU's) will run only simple task schedulers.

The Master Station uses an Atmel ATmega128 (128k code space, 4K SRAM)
with serial-to-Ethernet via a Lantronics XPort; probably the encrypted
version. Its security level (128-bit AES) is not state of the art
but may be enough for our purposes.

The RTU is battery operated and will run on some member of the TI MSP430
2xxx family.

We are currently addressing various threat scenarios, such as
the sabotage to an Queensland, Australian sewage system:

http://www.crime-research.org/analytics/501/

This was an inside job, but we're also concerned about some hacker
targeting our system as a personal challenge.

On the RF side, the transceivers use a proprietary frequency-shifting
scheme, but physical security for the RTU's can not be assured due to
the nature of the product and if an attacker steals one then the raw
RF messages will be visible.

The signals will be fairly infrequent and short; less than a dozen
bytes. My first idea was XORing them with the output stream of a
Galois LFSR. To ensure that routine polling queries would always
be different (and apparently random) I would use a seed value derived 
from the RTU serial number and a tap configuration supplied by
the Master Station.

However this scheme relies on the secrecy of the algorithm, which is bad
cryptography, even assuming that the microcontrollers' security fuses
afford good code protection; and yet the RTU has limited computing
resources so I'm not sure what would be the best practice in this
situation.

Any help appreciated;
TIA, Sean Quinlan

On Jan 7, 5:46=A0pm, Sean <no.s...@no.spam> wrote:

> The signals will be fairly infrequent and short; less than a dozen
> bytes. My first idea was XORing them with the output stream of a
> Galois LFSR. To ensure that routine polling queries would always
> be different (and apparently random) I would use a seed value derived
> from the RTU serial number and a tap configuration supplied by
> the Master Station.

You've made a creditable attempt at _starting_ to analyze the threat
scenario. However you haven't really detailed in your post exactly
what threats you're trying to prevent.

If you're merely attempting to prevent message spoofing, playback
attacks etc, try protecting the whole message with a rolling-code
encryption system. The one with which I'm most familiar is Microchip's
Keeloq (download the datasheet for the HCS300 encoder ASIC to see more
information). This particular scheme has been cracked so I wouldn't
actually use it

The approach here would be to send your message in the clear, or
encrypted with a simple algorithm of the type you describe, but then
follow it with a rolling-code ciphertext block; if the code doesn't
match, your base station should ignore it.

> The signals will be fairly infrequent and short; less than a dozen
> bytes. My first idea was XORing them with the output stream of a
> Galois LFSR. To ensure that routine polling queries would always
> be different (and apparently random) I would use a seed value derived
> from the RTU serial number and a tap configuration supplied by
> the Master Station.

It's already been pointed out that you should define your threat model
with more detail.

Your approach with XOR is vulnerable to for example:

- an attacker can flip single bits in the ciphertext that result in
flipped bits in the plaintext (at the same position)

- an attacker can remove a message from your channel, bringing sender/
receiver out of sync, and resulting in incorrect plaintext and
(hopefully just) denial-of-service.

- if you use a seed value to counter the latter, an attacker can
replay messages.

etc.

SNIP
> We need to secure both the RF and the Internet communications. I am new
> to the security issues involved and need a few clues on where to find
> techniques for small microcontroller-based systems.
SHIP
> The Master Station uses an Atmel ATmega128 (128k code space, 4K SRAM)
> with serial-to-Ethernet via a Lantronics XPort; probably the encrypted
> version. Its security level (128-bit AES) is not state of the art
> but may be enough for our purposes.
128 bit AES is a very hard nut to crack!
> The RTU is battery operated and will run on some member of the TI MSP430
> 2xxx family.
Do you have enough cycles for AES considering your power limitations? Every
processer cycle is so many nW...
If not, go for something like TEA ore self shrinking generators. Much
smaller but not as thoroughly verified
> We are currently addressing various threat scenarios, such as
> the sabotage to an Queensland, Australian sewage system:
> On the RF side, the transceivers use a proprietary frequency-shifting
> scheme, but physical security for the RTU's can not be assured due to
> the nature of the product and if an attacker steals one then the raw
> RF messages will be visible.
I saw an ASK RF protocol that used the property that an attacker can change
a 0 into a 1 but not the reverse. I can send you some pointers later

> The signals will be fairly infrequent and short; less than a dozen
> bytes. My first idea was XORing them with the output stream of a
> Galois LFSR. To ensure that routine polling queries would always
LFSR are  not very secure. Adding something non-linear may improve things,
but see the A5 breaks that this is difficult
An other approach is using a random timeslot, if you can synchronise your
clocks properly
> be different (and apparently random) I would use a seed value derived
> from the RTU serial number and a tap configuration supplied by
> the Master Station.

>
> However this scheme relies on the secrecy of the algorithm, which is bad
> cryptography, even assuming that the microcontrollers' security fuses
> afford good code protection; and yet the RTU has limited computing
> resources so I'm not sure what would be the best practice in this
> situation.
Dont even try....

Wim

>> The signals will be fairly infrequent and short; less than a dozen
>> bytes. My first idea was XORing them with the output stream of a
>> Galois LFSR. To ensure that routine polling queries would always

<clip>

> It's already been pointed out that you should define your threat model
> with more detail.

Yup.

> Your approach with XOR is vulnerable to for example:

<clip of ease of attacking this simple encryption scheme>

I developed a system recently which used small, very-low-power processors 
transmitting service meter readings.  Some form of encryption was clearly 
necessary, but I had very limited computing abilities at the transmitting 
end.  The most likely threat scenarios were not dire, but worth some 
protection none-the-less.

The solution I implemented, which was both easier and considerably more 
effective than I'd hoped for, was a very low overhead encryption algorithm: 
TEA (Tiny Encryption Algorithm). The entire code for it (about a dozen lines 
of C) is easy to find on-line - I just discovered that there's a version 
(including source) on WikiPedia.

Maybe this would work for you...
--
Mark Moulding

Mark Moulding wrote:
>> It's already been pointed out that you should define your threat model
>> with more detail.
> 
> Yup.

Ditto.

> The solution I implemented, which was both easier and considerably more 
> effective than I'd hoped for, was a very low overhead encryption algorithm: 
> TEA (Tiny Encryption Algorithm). The entire code for it (about a dozen lines 
> of C) is easy to find on-line - I just discovered that there's a version 
> (including source) on WikiPedia.

I find TEA (or preferrably XTEA) a great way to get reasonably strong 
encryption for most applications. If you have the horse power AES is 
more tested and has wider acceptance as a "strong" scheme, but it
costs you cycles and memory. Add some salt to every message and roll the 
keys every once in a while to get that warm and fuzzy feeling.

That's all good, but what I find more interesting with this problem is 
the key management. Obviously this goes back to the threat model 
discussion and will be highly depending on the surrounding circumstances.

The model I'm using for one system goes like this;

Each node receive a unique random key and a serial number in production. 
A central server stores the key/serial combination and when nodes are 
commissioned they need to communicate with that server. From there a 
session key can be established and the system is secure from that point 
forward.
The obvious weakness is that you need the central server and ability to 
communicate with it (in my case all the nodes have access to Internet so 
I maintain a couple of registration servers).
The good is that even if someone hacks a node, sucking out the 
production key by delayering the chip or whatever, they can only mess 
with that single unit's comms. The rest of the system is unaffected - so 
this thwarts bootleg manufacturers pretty efficiently and limits the 
damage to the node that was hacked (and was probably destroyed in the 
process anyway).

Another way would be to trust the installer. If there is a way to 
"marry" the node with the host in the installation process by entering a 
password on both sides, or by letting them communicate over a local 
channel (like a direct serial link), then that could establish a 
session/system key. Problem is that we expose the key exchange to the 
installer. If he's the enemy then the system is compromised. Sure, we 
could obfuscate the key exchange, but it can be hacked.

So are there better models? A PK-scheme would be nice, but that would 
require much more horse power. The implementations I've found using RSA 
are pretty heavy - is there a light-weight way?
While a PK-scheme would secure the session, it doesn't validate the 
authenticity of the node. The only way I can think of to do that is to 
hide a key inside the chip and hope that the attacker can't get it out.
So we have to trust the chip maker...

Just my 2c.

</A>