October 2015
30
M
icrocontrollers
Security considerations for embedded
designs in the new connected world
By Gordon Cooper,
NXP
As more embedded devices are
connected to the internet, becoming
part of the Internet of Things, more
opportunities come for hackers with
malicious intentions. Security is requi-
red to protect against their attempts
to copy IP, steal data, or hijack a
system. But it is hard to know just
how much security is needed when
designing a system using an
embedded microcontroller.
To simplify the security discussion, it helps
to consider security as three elements. In fig-
ure 1, an embedded device A needs to com-
municate with a remote location B. The three
components of security to consider are 1)
device integrity – securing access to device
A, 2) establishing trust with remote location
B through authentication and 3) secure mes-
saging between the two devices using data
encryption after trust is established.
Device integrity relates to how well the code
(or IP) and data on an embedded device are
protected from unauthorized access such as
a remote software hack, someone gaining
access through established user interfaces or
physical/probing attacks on the system hard-
ware. There are various ways to protect against
these attacks – requiring varying levels of cost
and complexity. Establishing trust between
devices involves one or both devices verify-
ing the authenticity of the other, to ensure
data is not being sent to or from an imper-
sonator. The typical way of establishing trust
is by asymmetric key encryption – where a
pair of keys (one private and one public) is
used for establishing trust. The private key
is used for encryption and the public key is
used for decryption. Common algorithms for
asymmetric key encryption are RSA and ECC.
Once trust is established, a symmetric encryp-
tion algorithm is used to protect the data as it
travels fromdevice A to location B. Symmetric
encryption uses the same key for encryption
and decryption. It is faster than asymmetric
encryption which is why asymmetric encryp-
tion isn’t used for all communication. The cur-
rent encryption standard isAES or Advanced
Encryption Standard, a symmetric key block
cipher that encrypts data in blocks of 128, 192
or 256 bits using a key of the same length.
While any algorithm is hackable given enough
time, it’s estimated that a brute force attack –
trying every combination (2128 or 3.4 x 1038)
to uncover the key – against an AES-128 block
cypher could take millions of years using mod-
ern supercomputers. AES-256 would require
2256 or 1.1 x 1077 combinations. Since either
AES-128 or AES-256 is suitably secure against
a brute force attack, the AES-128 is often a
better choice as it is 40% faster to implement.
Since there is little benefit to a brute force
attack against AES, hackers spend their time
trying to extract the AES keys. If the AES
keys are not well protected, it doesn’t matter
how secure the algorithm is. It would be like
having a six-inch thick steel door protecting
your house and then leaving the keys under
the doormat. Security is not a one-size-fits-all
requirement. How much security is required
in an embedded design depends on what you
are connecting to, what you are protecting
and how much damage is done if security is
breached. The columns in figure 2 represent
different levels of security that can be consid-
ered in an embedded design. The first column
represents a typical embedded application. If
the embedded device is not connected to the
internet – not part of a network – there’s no
need to worry about encryption algorithms,
establishing trust or key storage. There may
still be a reason to pay attention to device
integrity – particular if intellectual prop-
erty (IP) protection is important. Preventing
competitors from reading out the program
contents of internal flash protects a company
intellectual property from potential copycats.
For this protection, look for microcontrollers
that include built-in code read protection.
When IoT connectivity is required, it is time
to consider additional security features for
code and data protection. Adding software
security algorithms to a general purpose
microcontroller can provide all the require-
ments needed for securing messaging. Soft-
ware RSA or ECC can be used to establish
trust and a software version of AES can be
used for secure messaging. Keys are stored in
either flash or RAM and are often scrambled
using software techniques. Software AES algo-
rithm is no more or less secure than hardware
accelerated AES implementation. Figure 2
also highlights the benefit of replacing a gen-
eral purpose microcontroller running soft-
