[Cryptography] OpenSSL and random

[Peter Gutmann]

Combining replies to conserve bandwidth (incidentally, is it about time to
wind this up, and we'll reconvene in another six months as usual?):

Jeremy Stanley <fungi at yuggoth.org> writes:

>Keep in mind that "time" may also be a poor choice as many of these systems
>boot without a persistent state and so all start with their clocks reading
>the same value (e.g., 1970-01-01T00:00:00Z). 

Sure, lack of any kind of RTC was anticipated, which is why I used multiple
sources.  It's not really critical, as long as you have one per-device unique
value mixed in you'll get distinct keys for each device which is the important
bit, adding something that varies over time will give a different key on a
regen but it's not fatal if you don't get that.

Jason Cooper <cryptography at lakedaemon.net> writes:

>For scada systems in particular, the most likely attack vector is through the
>(typically) ethernet network connecting the HMIs to the scada devices.  So
>the current IP address and MAC address are easily discoverable.

Right, but it's not being used as a secret value, merely a diversifier.  As
long as you don't get multiple devices with the same MAC address you're fine.

>I presume you're thinking of putting ssh or TLS around the traditional
>TCP/modbus connection?  Because that's where the real weakness is. There's no
>need to try to exploit anything if the protocol includes a "force_{out,in}
>put_to" that the ladder logic then can't override.  :-)

I just see TCP over something, but not what it is.  Conveyor-belt static,
possibly (an actual event, turns out that 40kV of ESD and SCADA don't mix).

>Perhaps a better option is to include a "Cert Generation and Installation"
>step for the scada system rollout.  After all, rolling out a scada network is
>an activity conducted over several weeks (at least) by trained engineers. 

But they're either trained process control engineers or IT admins, not
security people.  They use phrases like "perfectly ordinary sodium iodide
gamma ray spectrometer" (another actual event), but not "perfectly ordinary DH
key exchange".  So successful rollout of a SCADA system doesn't mean secure
rollout of a SCADA system.

>If random numbers are still needed for DHE or other purposes, you could
>always pull some bits from the ADCs.

That's the killer with lots of these devices, you've got great sources of
entropy (see "gamma ray spectrometer" above, radioactive decay as the
definitive randomness source), but you can't get to any of it because it's
handled by a separate subsystem.  There's lots of cool parts in there, but
they don't talk to each other because they're all done by different groups. In
particular, the security part has a very low priority compared to the various
make-sure-things-don't-fail parts, so asking for access to the components
involved in making sure things don't fail invokes a no-by-default response.

Peter.