43 / 84
New-Tech Magazine Europe l 43
with location potentially an intrinsic
part of the value of the sensor data.
The concern here is how robust the
solution is in detecting and handling
failure cases. For example, either
through jamming the GNSS receiver,
or spoofing the input to the GNSS
receiver, it is just as important to
detect that the reported position is
different to reality as it is to protect
against a direct attack on the rest of
the system. Man-in-the-middle style
attacks on the sensor data passed
to the host will also be another
consideration. Being able to detect
both this and spoofing attacks and
alerting the end-application are
important aspects of incorporating
security into your design.
As the IoT era advances forward
security can no longer be an
afterthought. Implementing a
security regime into your product
is as essential as the device’s core
function.
dispersed sensors the favoured
approach is to enable an over-the-
air method. While the concept is
fairly straightforward, the chances
of this becoming an attack point
is high. Ensuring the downloaded
firmware image or patch is validated
prior to being flashed is essential.
This must include a process that
ensures the resulting image can be
authenticated and integrity-checked
before use; with an ability to back-
track to the previously authenticated
image should a security breach or
hardware problem be encountered
during the update process, whilst
also preventing older versions from
being accepted.
The next consideration is that of the
communications or transport layer.
There needs to be a mechanism for
the device to be able to authenticate
itself with the server, and vice versa.
Whatever the method used, the
device should be able to sign or
encrypt any data communicated with
the server. The ability to securely
manage the keys used for the
signing, decryption and encryption
processes will ensure that these can
be changed whenever necessary,
even on a per session basis. Data
being communicated is always open
to the potential of being intercepted
or compromised by man-in-the-
middle attacks, including at the
device interface level. Hence taking
unauthorised control of the device is
another possibility that needs to be
avoided at all cost.
Access to device functionality is
often via a number of defined APIs.
Unfortunately, the access to device
features and the implications for
security can often be overlooked.
Those wishing to exploit or
compromise a device, even if for
the fun of it, usually have a lot of
time available to probe for open
APIs and experiment with the
interrelationship between them and
device functionality. Sometimes
APIs incorporated within code
provide access not only to standard
features and capabilities but also
to premium or paid-for services.
Developers also frequently provide
undocumented APIs for their own
testing and configuration so it is
imperative that these are protected
as well. Hence, formal authentication
and authorisation techniques should
be employed to allow access to or
enable such API’s.
The final consideration is that of
robustness for those applications
that source data from external
devices, such as a GNSS receiver,