April 18
8
C
over
S
tory
Security is basic
For every connected device there are three
basic rules. The most basic security rule is that
every access is authenticated and authorized to
that only someone who is allowed to do some-
thing can have access. The next rule is that all
communication should be encrypted. The last
rule, more an awareness, is that all software and
firmware can be updated somehow.
But I want to point that out a little bit more
in an example that comes from industrial
IoT. The example in Figure 2 shows a sim-
ple sensor setup, which is connected via ISO
standard MQTT, Message Queuing Telemetry
Transport, a quite often-used protocol in IoT,
located on the application layer, like HTTP,
FTP, or DNS on top of TCP/IPN Ethernet.
It is a simple subscribe and publish protocol,
that allows a sensor, or publisher, to publish
its data as a topic. For example, in Figure 2 we
have the topic “Factory 1, floor 1, robot 3, oil
temperature”, which is regularly published by
one sensor. If another client is working as a
process monitor, it can subscribe to “Factory
1, floor 1, robot 3, #” and then get all that data.
So, it’s a very simple, but effective, way to track
control and coordinate process data.
Now, let’s apply the first security rule here,
where every access should be authenticated
and authorized. For authentication, we need
all the participants to be addressed, which
means every sensor, every client, and every
device needs its own username and password,
or its own key file. Authorization is to do
what? In this example, the sensor on the top
left is only allowed to send to the topic “Fac-
tory 1, floor 1, robot 3, oil temperature”. Being
able to distinguish every detail about who is
allowed to do what really makes sense, even
when you are in a closed network, as there are
intruders that might get access. Authentica-
tion and authorization might not be sufficient,
especially when there is no encryption in the
network. When an unencrypted network cli-
ent logs in, the credentials are transported in
plain text, meaning everybody inside the net-
work can sniff them out very easily. The only
thing that you need is a network monitor and
access to that network. We can avoid that by
encrypting all the transport inside the net-
work. MQTT is really simple because you can
set it up on top of any security layer in TCP/IP.
The third rule is that every device’s soft-
ware and firmware can be upgraded. Why
is that necessary? Well, let’s go back in time,
in 2014,when Heartbleed was an issue in
OpenSSL, which allowed all the encrypted
data be fully revealed to anyone. On a level
of 0 to 10, it got an 11. That means all the
encryption that we did was simply in vain. It
could only be fixed by updating to a fixed ver-
sion of the software. A second bug came up
in 2014 called Poodle. Not as problematic as
Heartbleed, but still quite an issue, as it also
affected the clients through a fallback from
TLS to SSL3, which could be forced by a cli-
ent, could simply allow a “man in the middle
attack”. Also, the fix was to update the soft-
ware, and there is no proof that it will not
occur again. Recently we’ve seen the Spectre/
Meltdown issues, which are not as critical, as
they only affect machines where already for-
eign code can be executed.
How to update doesn’t matter as long as it
will be done, whether locally or remotely. All
clients, all servers, all devices that host some
firmware, host some software needs to have
the ability to be fixed in case of a security prob-
lem. For example, when it comes to security,
Kontron offers designers secure, trusted boot
software to enable a chain of trust to ensure
that the BIOS running in the system is authen-
ticated. It is the same on the OS level, with
secured operating systems, and there can be
an additional level on the application side. All
Kontron boards can be equipped with a Wibu
Systems security chip with related software to
allow full IP protection for running software,
where the application code can be encrypted,
and therefore, not be reverse engineered.
So we can have fully software authorization
from BIOS to the application level.
Another use case involves different licensing
models. Software can be restricted by runtime,
number of program fetches, and other factors,
presenting completely new business cases
where software as a service can be brought
down to the edge layer.
SMARC
When you build an intelligent electronic
device, you can go with an out-of-the-box
solution, or a full custom design, or some-
thing in-between, a modular scalable solution
eHPC (EMBEDDED HIGH PERFORMANCE COMPUTING) IN EMBEDDED CLOUD
CLOUD
Off-Premise
Data Storage
EMBEDDED CLOUD
On-Premise
Real Time Switching
HMI
Brown Field
PLC, ...
Gateway
Gateway
Edge Computer
Sensors,
Actuators
Cloud Host Platform
Central &
Remote Management
Level
Monitoring &
Process Control Level
Factory Floor &
Field Level
=
Control &
Automation Level
Visualization &
Control
Figure 1. Computing at the Cloud, Fog, and Edge levels.
Possibilities start here
// 2
EXAMPLE WITH MQTT – UPGRADABILITY
MQTT
Broker
sensor
sensor
Process
Monitoring
Mobile
Monitoring
Figure 2. A simple sensor setup connected via ISO standard Message Queuing Telemetry Transport
