IoT Security

Syllabus
This module will cover the following

• Importance of security in IoT

• Threat modeling
• Code signing
• Encryption
• Wireless security

2 © 2020 Arm Limited

Why security is critical in IoT
Context:
• Billions of connected devices already deployed, used increasingly more to collect
personal information (medical IoT, wearables, smart homes) or serve critical services
(automotive IoT, energy distribution)

Challenges:
• System heterogeneity (sensing, computation, communication),
• Complex interactions (systems of systems)
• Hundreds of new types of devices appear monthly
• Software evolving continuously
• Many device in use after vendors discontinued support/went into liquidation

3 © 2020 Arm Limited

Identifying vulnerabilities
Gather detailed knowledge about end-to-end system architecture and the key building blocks

Understand how information flows between blocks, in what order, and based on what conditions

Identify potential breaching points of each building block

Establish trust boundaries that is the component most likely to be compromised first

Reflect on plausible attack scenarios and incentives an attacker may have to tamper with a system

4 © 2020 Arm Limited

Threat modeling
Structured analysis of a system’s vulnerabilities from an attacker’s perspective

Goals:
• Identify security risks
• Quantify their severity
• Estimate likelihood of occurrence
• Reason for counteraction and prevention mechanisms
• Prioritize implementation of such mechanisms

Different threat modeling methodologies can be adopted:

• Open Threat Taxonomy
• ENISA IoT
• OWASP IoT
• ITU-T X.800
• Others

5 © 2020 Arm Limited

Open Threat Taxonomy
The confidentiality, integrity, availability (CIA) triad applied across different threat groups
1. Physical threats (incidents or actions that could lead to system damage, destruction, or
theft – e.g., natural disaster, cooling/ventilation failure, vandalism)
2. Resource threats (failure of information system due to disruption of resources required
for operation – e.g., communication services, external storage, power supply)
3. Personnel threats (deliberate or accidental actions of humans involved in the
management/interactions with a system that may harm the system; damage as a result
of social engineering that leads to system authentication compromise)
4. Technical threats (actions by an attacker that could harm the information system)

Multiple threats (each with their ID) can be classified in each of these groups, the severity
of each being rated from 1 to 5 (the higher the rating, the more likely that threat).

6 © 2020 Arm Limited

Open Threat Taxonomy
Technical threats
• Credential discovery, e.g., via sniffing (TEC-007), brute force (TEC-008), pre-
computational attacks (TEC-011)
• Escalation (TEC-013) or abuse (TEC-014) of system privileges
• Cryptanalysis (TEC-019)
• Denial of Service (DoS) (TEC-021)
• Manipulation of data in transit (TEC-023) or capture of data in transit via different
methods (TEC-024 – TEC-026)
• App exploitation via input manipulation (TEC-031), code injection (TEC-033), fuzzing
(TEC-037), reverse engineering (TEC-038), etc.

7 © 2020 Arm Limited

ENISA IoT threat taxonomy

• Part of a broader
Baseline Security
Recommendations
for IoT in the
context of Critical
Information
Infrastructures
• Aligned with the
general ENISA
threat taxonomy,
but specifically
focused on IoT

8 © 2020 Arm Limited

Impact assessment of IoT threats

• The severity of different threats ranked

as Medium, High, or Crucial, based on
interviews with IoT experts
• Weighted average of responses, based
on a five-step scale (0 – no importance;
5 – crucial importance)
• Impact may vary depending on the IoT
use case scenario

9 © 2020 Arm Limited

OWASP Internet of Things
OWASP – Open Web Application Security Project
Helping stakeholders understand security Top 10 things to avoid
1. Weak, guessable, or hardcoded passwords
• OWASP IoT project groups different community- 2. Insecure network services
led initiatives to strengthen security into three 3. Insecure ecosystem interfaces
categories: Seek & Understand, Validate & Test,
4. Lack of secure update mechanism
and Governance.
5. Use of insecure or outdated components
• Identifies ten key things to avoid from a security
perspective when building, deploying, or 6. Insufficient privacy protection
managing IoT systems. 7. Insecure data transfer or storage
8. Lack of device management
9. Insecure default settings
10. Lack of physical hardening.

10 © 2020 Arm Limited

OWASP IoT Attack Surface
Ecosystem Access Control (implicit trust, enrolment security, lost access procedures, etc.)

Device memory (cleartext usernames/passwords, encryption keys, etc.)

Device physical interfaces (firmware extraction, privilege escalation, reset to insecure state)

Device web/admin/cloud web interface (SQL injection, XSS, account lockout, 2FA, etc.)

Device firmware (hardcoded credentials, sensitive info disclosure)

Device network services (injection, DoS, poorly implemented encryption, buffer overflow, etc.)

11 © 2020 Arm Limited

OWASP IoT Attack Surface
Local data storage (unencrypted data, lack of integrity checks)

Update mechanism (updates encrypted/unsigned, update location writable, etc.)

Mobile application (implicitly trusted by cloud, user enumeration, transport encryption, etc.)

Third parties (device information/location leaked, unencrypted PII)

Backend APIs (inherent trust, weak authentication, weak access control)

Ecosystem communication (health checks, heartbeats, deprovisioning)

12 © 2020 Arm Limited

Example: Fitness tracking system

13 © 2020 Arm Limited

Example: Fitness tracking system

Packet sniffing,
DoS, code injection

14 © 2020 Arm Limited

Example: Fitness tracking system

Packet sniffing, Packet sniffing,

DoS, code injection protocol reverse
engineering

15 © 2020 Arm Limited

Example: Fitness tracking system

User impersonation,
fake measurements
Packet sniffing, Packet sniffing,
injection, exfiltration
DoS, code injection protocol reverse
engineering

16 © 2020 Arm Limited

Example: Fitness tracking system

User impersonation,
fake measurements
Packet sniffing, Packet sniffing,
injection, exfiltration
DoS, code injection protocol reverse
engineering

Service impersonation,
malware injection
17 © 2020 Arm Limited
Mitigating risks

Hardware (attackers Code (signed and

Strengthen security
should not be able to tested
across the entire end-
compromise device via firmware/software,
to-end system
direct physical access) integrity checks)

Service semantics
Encrypted channels
(communication robust
(data never exchanged
to DoS, replay attacks,
in plaintext)
account hijacking, etc.)

18 © 2020 Arm Limited

Code signing

• Enables devices to verify whether, for e.g.,

a firmware update can be trusted
• Cryptographic hash generated to confirm
code authenticity and integrity
• Key idea: map data of any size to a fixed
“digest,” using a one-way function (i.e.,
operation that is difficult to invert).
• Public-key-infrastructure (PKI) used to
provide assurance about who signed code.
• Signature embeds a certificate issued by a
certificate authority (CA).

19 © 2020 Arm Limited

Network security
Encryption
• Encryption: Process of
transforming plaintext
message into cipher-
text using a key and
encryption algorithm
• Algorithm involves a
set of mathematical
operations,
permutations,
substitutions, etc.
• Difficult for an
attacker intercepting
messages to figure
out the key

20 © 2020 Arm Limited

Encryption principles
Secrecy

Length of encryption key directly influences level of secrecy

Key design is particularly critical, for e.g., only 100 combinations exist for 2-digit pad
locks → not so difficult to brute-force (exhaustive search)

Work factor: Effort or time required by an attacker with given resources to infer an
encryption key

Work factor for breaking a key by exhaustive search is exponential in key length
→ the longer the key, the higher the work factor

21 © 2020 Arm Limited

Encryption principles
Redundancy
• Problem: When the ciphertext is short, an attacker may generate random fake
messages of the same length to figure out even a key that is long
• Solution: Add information to encrypted messages that is not needed to understand the
original message
• Redundancy may decrease the likelihood of generating a valid message
• Possible approach: Pad messages with data derived from messages, for e.g., a modified
copy or hash of the original message
• Hash functions map data of arbitrary size onto a fixed-size string (hash)

22 © 2020 Arm Limited

Encryption principles
Freshness

Problem: How to verify Possible solution: Receiver keeps a Messages with a known
that a message was not Include a “token” in message for T seconds, token that are older than
already sent every message that is compares new messages T seconds will be ignored
(replay attacks) valid only for a limited to previous ones, and
duration T (e.g., 10 discards any duplicates
seconds)

23 © 2020 Arm Limited

Symmetric key encryption

Use the same key for both encrypting and decrypting messages

Key provisioned at device manufacturing

Common approach:
Block ciphers (take n-bit blocks of plaintext and convert to n-bit blocks of ciphertext)

Multiple stages divide input into groups and perform a set of operations
- Substitutions and permutations;
- Split, pass through round functions, XOR

24 © 2020 Arm Limited

Feistel ciphers
• Same circuitry used for encryption and decryption

• Messages split into blocks

• Each block processed iteratively
• A “round” function F operates on one half of a block and uses round sub-keys
• Round function does not need to be invertible
• The other half of the block is swapped at the input of the following round

• Feistel ciphers used in multiple symmetric encryption schemes:

• Data Encryption Standard (DES) and
• eXtended Tiny Encryption Algorithm (XTEA)

25 © 2020 Arm Limited

Feistel ciphers
Operation

1. Divide block into two parts of equal size

(L0, R0)
2. At each round i
Li+1 = Ri
Ri+1 = Li  F(Ri,Ki)
3. Ciphertext is
(Rn+1, Ln+1)

Decryption process uses the same sub-keys,

but in reverse order

26 © 2020 Arm Limited

Example

Plaintext: 0xFACCBF0D L0 = 0xFACC R0 = 0xBF0D

Round function: F(Ri,Ki) = Ki  (Ri << 4) L1 = R0= 0xBF0D R1 = L0  (K0  (R0 << 4))
 is the exclusive OR operator R1 = 0xFACC  (0x1010  0xF0DB)
<< is the circular shift left operator R1 = 0xFACC  0xAF1D = 0x55D1
16-bit key, sub-keys K0 = 0x1010, K1 = 0xAB2F, …
L2 = R1 = 0x55D1 R2 = L1  (K1  (R1 << 4))
R1 = 0xBF0D  (0xAB2F  0x5D15)
R1 = 0xBF0D  0xF63A = 0x4937
…

27 © 2020 Arm Limited

Advanced Encryption Standard (AES)

Based on Rijndael cipher (substitution-permutation network)

Works with 128-bit blocks arranged in 4x4 column-major order matrixes of bytes

Multiple rounds, whose number is determined by key size

Key expanded into round keys through a Rijndael key schedule

(byte rotation, exponentiation of 2 to user-specified value, S-box)

28 © 2020 Arm Limited

AES operation
At each round (except the last) perform the following:

1. SubBytes: Non-linear byte substitution using a lookup table (S-box)

• First 4 bytes indicate row,
• Last 4-bytes indicate column
• Operations in Galois Field with 28 elements
2. ShiftRows: Rotate left bytes on each row i with i - 1 positions
3. MixColumns: Multiply in GF(28) a matrix with each column
(diffusion – obscure connection between key and ciphertext)
4. AddRoundKey – XOR between source columns and columns of round key matrix

Columns not mixed at last round.

29 © 2020 Arm Limited

Diffie-Hellman key agreement
Secure establishment of cryptographic key over an untrusted channel

01 02 03 04 05
Two parties First selects a Second picks a Second party Both results
agree publicly secret prime secret number computes Ab will be the
on two prime number a, b, computes mod p, first same, i.e.
numbers computes B = gb mod p, party gab mod p.
(generator g, A = ga mod p, and sends B to calculates This is the
and modulus p) then sends A first party Ba mod p. shared secret

30 © 2020 Arm Limited

Asymmetric encryption
Also known as public key encryption
• Sender uses public key
of recipient to encrypt
messages
• Recipient uses own
secret private key to
decipher messages
• The approach
addresses the
challenges of key
distribution
• Easy to generate public
key from private key
• Extremely difficult to
guess private key

31 © 2020 Arm Limited

The Rivest–Shamir–Adleman (RSA) algorithm

• Asymmetric encryption algorithm based on prime number factorization

• Principle: Find three very large numbers e, d, n such that

• It should be difficult to find d if e, n, and ciphertext are known

• m is the original message
• The pair (e, n) constitutes the public encryption key
• d is the decryption key

32 © 2020 Arm Limited

RSA operation
1. Randomly choose two large prime numbers and
2. Calculate the modulus

3. Calculate totient

4. Choose a number , such that

• )
• is co-prime with and

5. Find , such that

33 © 2020 Arm Limited

Example
1. Pick and (both prime numbers, but in practice these should be very large)
2.
3.
4. Choose and co-prime with 6 and 14
is the only possible choice → public key is thus (5,14)
5. Find , such that

34 © 2020 Arm Limited

Elliptic curve cryptography (ECC)
• Based on the algebraic structure of elliptic curves (i.e., ) over finite fields, on
which group operations are performed

• Main advantage: Can provide equivalent level of security as with RSA, but with
much smaller key size

35 © 2020 Arm Limited

ECC key agreement

• Key idea: Scalar multiplication is a one-way • Generator (): Point on the elliptic curve that
function, i.e. easy to compute , but very hard to generates a cycling group of points by repeated
find when and are known additions
• Ord(G) = n, but also the smallest positive integer
, such that
• Co-factor

• Domain parameters
• : field parameter (modulo)
• : define the curve
• All parameters known to communicating
parties and potential eavesdroppers

36 © 2020 Arm Limited

Elliptic Curve Diffie-Hellman (ECDH) key establishment

• Alice picks a random number (private key), s.t. sends

• Bob picks a random number (private key), s.t. sends
• Alice computes , Bob computes
• Result obtained by both is the same: → shared key established
• An attacker has no way of computing , unless they know or , or they solve the elliptic
curve discrete logarithm problem that is hard
• Curves worked by mathematicians and proven to be robust should be used

37 © 2020 Arm Limited

Securing wireless communications
Data confidentiality is particularly important in wireless communications, since the
transmission medium is inherently broadcast (anyone can listen)

Wi-Fi is the most popular wireless technology and employed in a range of IoT scenarios.

Wired Equivalent Privacy (WEP) and Temporal Key Integrity Protocol (TKIP) used
historically, but shown to have flaws and replaced with Wi-Fi Protected Access II (WPA2)

The latest Bluetooth specification relies on an ECDH key agreement protocol and
connections are subsequently secured with AES

38 © 2020 Arm Limited

WPA2
• Two protocols defined for initial authentication:
• Via Pre-shared key (PSK) or
• Using an authentication server and the Extensible Authentication Protocol (EAP) with different
authentication options (TLS, Protected EAP, etc.)
• After authentication, a shared secret key, known as Pairwise Master Key (PMK) is
generated that is derived from a password that is cryptographically hashed
• In PSK mode, the PMK is the PSK
• Four-way handshake used to
• enable the access point and client to prove to each other that they know the PSK/PMK, without
disclosing the key
• establish a Pairwise Transient Key (PTK) that is used to encrypt the traffic
• AES then used to encrypt payload

39 © 2020 Arm Limited

Transport layer security (TLS)
Provides encryption, authentication, and data integrity to applications
• Shared secret negotiated between peers
• Peers agree on TLS protocol version and choose
cipher suites via three-way handshake
• Both authenticate their identity based on
established chain of trust
• 32-byte session identifier sent as part of
ServerHello message during TLS negotiation
• Chain of trust used to verify the identity of
parties (via certificate authority)
• Once a shared secret is established, this is used
as a symmetric key to encrypt all TLS records.
• Each message signed with a Message
Authentication Code (MAC)

40 © 2020 Arm Limited

Coming next
Module Contents
Current and Future IoT • Machine learning
Trends • Edge computing
• Platform Security Architecture
• Research topics

41 © 2020 Arm Limited