IoT Security Image: xkcd How is securing IoT different from - - PowerPoint PPT Presentation

iot security
SMART_READER_LITE
LIVE PREVIEW

IoT Security Image: xkcd How is securing IoT different from - - PowerPoint PPT Presentation

IoT Security Image: xkcd How is securing IoT different from securing any other system? IoT is a system of systems, with A great deal of heterogeneity (sensing, computation, communication, energy) New types of devices appearing all


slide-1
SLIDE 1

IoT Security

Image: xkcd

slide-2
SLIDE 2

How is securing IoT different from securing any other system?

  • IoT is a system of systems, with
  • A great deal of heterogeneity (sensing, computation,

communication, energy)

  • New types of devices appearing all the time
  • Some discontinued (e.g. due to vendor bankruptcy),

yet still on the market (e.g. Jawbone)

  • Software continuously evolving
slide-3
SLIDE 3

Classic pillars of Information Assurance remain the same

  • Confidentiality – keeping information secret
  • Integrity – ensuring information not modified

(accidentally or purposely) without being detected

  • Authentication – data originates from a known

(identified) end point

  • Non-repudiation – the actions of a user/system

cannot be denied once performed

  • Availability – the system/data is available when

needed

slide-4
SLIDE 4

Identifying vulnerabilities and mitigating risks

  • Start by acquiring in depth knowledge of the

architecture and the key entities involved

  • Identify potential entry points for each entity
  • Understand the data flow paths
  • Define trust boundaries (typically the IoT device

considered the easiest to compromise, but the trust boundary could be pushed to the GW, if secured)

  • Conceive plausible attack scenarios (this is mostly

based on previous experience plus curiosity)

slide-5
SLIDE 5

Threat modelling

  • The process of analysing in a structured way the

vulnerabilities of a system from the point of view of a hypothetical attacker

  • Helps identifying risks, quantifying their likelihood and

potential severity, and prioritising mechanisms for mitigation/prevention

  • Different methodologies/taxonomies
  • STRIDE (Microsoft)
  • Open Threat Taxonomy
  • ITU-T X.800
  • ENISA (general – Jan. 2016 + IoT specific – Nov. 2017)
  • OWASP IoT
  • Others
slide-6
SLIDE 6

STRIDE

  • Strictly speaking not IoT specific, but threats can be

applicable across different components of an IoT systems/service

Threat Relevant IA properties Spoofing Authentication Tampering Integrity Repudiation Non-Repudiation, Auditing Information Disclosure Confidentiality Denial of Service Availability Elevation of Privileges Authorisation

slide-7
SLIDE 7

Open Threat Taxonomy

  • Physical (actions that could lead to system theft/harm

destruction – e.g. HVAC failure, natural disaster, vandalism)

  • Resource (failure of information system due to disruption of

resources required for operation – e.g. power supply, communication services)

  • Personnel (deliberate or accidental actions of employees that

can harm a system, social engineering)

  • Technical (technical actions by an attacker that could harm

the information system)

  • The CIA triad applies across all these groups.
  • Multiple threads within each group, rated from 1 to 5.
slide-8
SLIDE 8

Open Threat Taxonomy – Technical threats

  • Credential discovery (sniffing, brute forcing,

cracking)

  • Escalation/abuse of system privileges
  • Cryptanalysis
  • DoS
  • Data capture/manipulation in transit
  • App exploitation via code injection, reverse

engineering, input manipulation, API abuse, etc.

slide-9
SLIDE 9

ENISA IoT threat taxonomy (Nov. 2017)

Consistent with the threat taxonomy released in Jan 2016, but easier to navigate and IoT focused

slide-10
SLIDE 10

ENISA IoT threat taxonomy (Nov. 2017)

slide-11
SLIDE 11

IoT threats impact (ENISA)

slide-12
SLIDE 12

OWASP IoT Project

  • OWASP (Open Web Application Security Project) –

non-for profit initiative, focused on improving software security

  • IoT project “designed to help manufacturers,

developers, and consumers better understand the security issues associated with the Internet of Things, and to enable users in any context to make better security decisions when building, deploying,

  • r assessing IoT technologies.”
slide-13
SLIDE 13

OWASP IoT Attack Surface

  • Ecosystem (general)
  • Device memory (sensitive data)
  • Device physical interfaces (privileges, debug ports, FW

extraction, etc.)

  • Device web/mobile interface/app (credential management)
  • Device firmware (data exposure, vulnerable services)
  • Device network services (injection, DoS, FW OTA block, replay

attacks, buffer overflows, etc.)

  • Admin interface (credentials mgmt., 2FA)
  • Local data storage
  • Cloud interface
  • Privacy
  • Several others
slide-14
SLIDE 14

Example – fitness tracking systems

wristband user smartphone wireless router Internet cloud server BLE Wi-Fi

slide-15
SLIDE 15

Example – fitness tracking systems

wristband user smartphone wireless router Internet cloud server BLE Wi-Fi Packet sniffing, DoS, code injection

slide-16
SLIDE 16

Example – fitness tracking systems

wristband user smartphone wireless router Internet cloud server BLE Wi-Fi Packet sniffing, DoS, code injection Packet sniffing, protocol reverse engineering

slide-17
SLIDE 17

Example – fitness tracking systems

wristband user smartphone wireless router Internet cloud server BLE Wi-Fi Packet sniffing, DoS, code injection Packet sniffing, protocol reverse engineering User impersonation, false measurement injection (selfish user)

slide-18
SLIDE 18

Example – fitness tracking systems

wristband user smartphone wireless router Internet cloud server BLE Wi-Fi Packet sniffing, DoS, code injection Packet sniffing, protocol reverse engineering User impersonation, false measurement injection (selfish user) Service impersonation, malware injection

slide-19
SLIDE 19

How to mitigate such a multitude

  • f risks?

Efforts needed across the entire end-to-end system

  • Hardware (device cannot be compromised through

direct physical access)

  • Code (firmware/software trustworthy)
  • Data not sent in plaintext (encryption)
  • Service semantics (communication robust to DoS,

replay attacks/account hijacking, etc.)

slide-20
SLIDE 20

Hardware security

How to ensure that keys stored on a device cannot be extracted easily? How to ensure the boot process remains untampered even when the application might get compromised? Note: might not be possible to make device completely safe against attacks, yet damage can be limited through several approaches.

slide-21
SLIDE 21

One-Time-Programmable (OTP) memory

  • Permanently programmed memory cells with strong

security (state-of-the-art today)

  • Access tightly controlled, difficult to reverse engineer
  • Programmed during IC or subsequent system

manufacturing.

  • With some, possible to destroy stored keys in response

to tamper attempts.

  • Secure key injection typically used to deploy randomly

generated keys.

  • Security may be maximized if the IC generates its own

keys using hardware designed into the device.

slide-22
SLIDE 22

Electrically Erasable Programmable Read Only (EEPROM) memory

  • Used as separate key/bootloader memories.
  • Used in multichip modules, drawing cryptographic

boundary around the subsystems.

  • Key injection used to provision secret keys.
  • Possible to bar EEPROM writing instructions from

app code.

  • Can disable EEPROM writing completely via

configuration fuses - even firmware updates will not be allowed

slide-23
SLIDE 23

Code signing

  • Devices should be able to verify whether the code

pushed by a developer can be trusted (think about firmware updates)

  • Typically a cryptographic hash produced to confirm

the authenticity and integrity of the software

  • Key idea: map data of any size to a fixed string, using

a one-way function (i.e. difficult to invert).

  • Public-key-infrastructure (PKI) used to provide

assurance about who signed the code. Signature embeds a certificate issued by a certificate authority (CA).

slide-24
SLIDE 24

Code signing

*Cisco

slide-25
SLIDE 25

Network security - encryption

Simple encryption model – transforming plaintext into cyphertext using some key; attacker intercepts messages, tries to figure out key

*tutorialspoint.com

slide-26
SLIDE 26

Encryption principles - secrecy

  • The secrecy is within the key - its length is a major

design issue (e.g. locks: 2 digits = 100 combinations)

  • The longer the key, the higher the work factor!
  • Work factor for breaking the key by exhaustive

search is exponential in key length.

slide-27
SLIDE 27

Encryption principles - redundancy

  • Encrypted message must contain some information

that is not needed to understand the original message

  • Even if the key is long, an attacker may generate

fake messages when the ciphertext is short by using random numbers

  • Adding redundancy decreases the likelihood of

generating a valid message,

  • But at the same time makes it easier to break
  • riginal messages overheard
slide-28
SLIDE 28

Encryption principles - freshness

  • Some method is needed to avoid replay attacks (i.e.

allow to verify that the message was recently sent)

  • One possible solution is to include a timestamp in

every message that is valid only for a limited time T (e.g. 10 seconds)

  • Receiver keeps a message for T seconds, compares

new messages to previous ones, and filters out duplicates.

  • Messages older than T seconds will be discarded as

considered too old.

slide-29
SLIDE 29

Symmetric key encryption

Symmetric-key algorithms use the same key for encryption and decryption Key typically provisioned at device manufacturing Block ciphers are most common (take n-bit blocks of plain text and convert to n-bit blocks of ciphertext) Multiple stages break the input into groups and perform a set of operations

Substitutions and permutations; Split, passed through round functions, XORed

slide-30
SLIDE 30

Feistel cipher

  • Encryption and decryption are very similar/identical
  • Message split into blocks and iterated with a ‘round’

function F that operates on half of the block with round sub-keys

  • Round function does not have to be invertible
  • Several schemes employ this, including
  • DES (Data Encryption Standard) and
  • XTEA (eXtended Tiny Encryption Algorithm)
slide-31
SLIDE 31

Feistel cipher

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 uses the sub- keys in reverse order

slide-32
SLIDE 32

Example

Plaintext: 0xAABBCCDD Round function: F(Ri,Ki) = Ki  (Ri >> 2) ( is the exclusive OR operator and >> is circular shift right) 64-bit key, sub-keys K0 = 0x1A2B, K1 = 0x3F07 L0 = 0xAABB, R0=0xCCDD L1 = , R1=

slide-33
SLIDE 33

Example

Plaintext: 0xAABBCCDD Round function: F(Ri,Ki) = Ki  (Ri >> 2) ( is the exclusive OR operator and >> is circular shift right) 64-bit key, sub-keys K0 = 0x1A2B, K1 = 0x3F07 L0 = 0xAABB, R0=0xCCDD L1 =R0=0xCCDD, R1=L0  (K0  (R0 >> 2))

slide-34
SLIDE 34

Example

Plaintext: 0xAABBCCDD Round function: F(Ri,Ki) = Ki  (Ri >> 2) ( is the exclusive OR operator and >> is circular shift right) 64-bit key, sub-keys K0 = 0x1A2B, K1 = 0x3F07 L0 = 0xAABB, R0=0xCCDD L1 =R0=0xCCDD, R1=L0  (K0  (R0 >> 2)) = 0xAABB  (0x1A2B  0x7337) = 0xAABB  0x691C = 0xC3A7

slide-35
SLIDE 35

Example

Plaintext: 0xAABBCCDD Round function: F(Ri,Ki) = Ki  (Ri >> 2) ( is the exclusive OR operator and >> is circular shift right) 64-bit key, sub-keys K0 = 0x1A2B, K1 = 0x3F07 L0 = 0xAABB, R0=0xCCDD L1 =R0=0xCCDD, R1=L0  (K0  (R0 >> 2)) = 0xAABB  (0x1A2B  0x7337) = 0xAABB  0x691C = 0xC3A7 L2 =R1= 0xC3A7, R2=L1  (K1  (R1 >> 2)) …

slide-36
SLIDE 36

Advanced Encryption Standard (AES)

  • Employs a Rijndael cypher

(substitution-permutation network)

  • Fixed block size (128 bits) arranged in a 4x4 column-

major order matrix of bytes

  • Key size determines the number of rounds
  • Key expanded into round keys through a Rijndael

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

slide-37
SLIDE 37

AES operation

At each round (except last): 1. SubBytes non-linear byte substitution using a lookup table (S-box) – first 4 bytes indicate row, last 4-bytes indicate column – Galois field GF(28) 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.

slide-38
SLIDE 38

Asymmetric encryption

  • Also known as public-key encryption
  • Circumvents problematic key distribution
  • Use a public key to encrypt messages

(known to anyone) and decrypt with a private key

  • Easy to generate public key from private key
  • Extremely hard to guess private key
slide-39
SLIDE 39

Asymmetric encryption

*The Globus Toolkit 4 Programmer's Tutorial

slide-40
SLIDE 40

The RSA cryptosystem (Rivest–Shamir–Adleman)

  • Core idea based on prime number factorisation
  • Find three very large numbers e, d, n such that

(𝑛𝑓)𝑒 = 𝑛 𝑛𝑝𝑒 𝑜 where it is difficult to find d if e, n, and m are known. e and n will together make the encryption key, d will be the decryption key, and m is the message.

slide-41
SLIDE 41

RSA operation

  • 1. Randomly choose two large prime numbers p and q
  • 2. Compute n = p × q
  • 3. Compute totient function (n) = (p − 1) × (q − 1)
  • 4. Choose a number e, such that 1<e<(n) and e is co-

prime with (n) and n (only positive factor that divides them is 1)

  • 1. Find d such that d × e = 1 (mod (n)), i.e.

Public key consist of (e,n), private key (d,n)

slide-42
SLIDE 42

RSA operation

Encryption: c = me (mod n) Decryption: cd = (me)d = m (mod n)

slide-43
SLIDE 43

Example

  • 1. Pick two prime numbers, say p=2 and q=7

(remember: in practice these have to be large!) 2. n = 14

  • 3. (n) = 1 x 6 = 6
  • 4. Choose 1<e<6 and co-prime with 6 and 14; only

e = 5 remains as an option -> public key is (5,14) 5. 5 x d (mod 6) = 1 - > d = 11 m = 2 - > c = 25 (mod 14) = 4; m’ = 411 (mod 14) = 2

slide-44
SLIDE 44

Diffie-Hellman key exchange

Mechanism for exchanging cryptographic keys over a public channel in a secure way 1. The two parties agree publicly on two prime numbers (a generator g and a modulus p) 2. One party selects a secret prime number a, computes ga mod p, and send the result A to the other party. 3. The other party does the same with a secret number b, computes B = gb mod p, and sends this back. 4. First party computes Ab mod p, second party computes Ba mod p. 5. The result will be the same, i.e. gab mod p (shared secret)

slide-45
SLIDE 45

Elliptic curve encryption

  • Based on the structure of elliptic curves (y2=x3 +ax +b) over

finite fields, on which group operations are performed

  • Key advantage: smaller keys than with RSA required to

provide equivalent security

slide-46
SLIDE 46

Elliptic curve encryption

  • Key idea: scalar multiplication is a one way function

(easy to compute Q = k x P), but very hard to find k when P and Q known.

  • Generator – point on the curve that generates a cycling

group of n points by repeated additions (order)

  • k – smaller number such that k x G = 
  • Co-factor h = (total number of points on curve)/n

should be as close to 1 as possible.

  • Field parameter p (modulo)
  • Domain parameters {p, a, b, G, n, h}
slide-47
SLIDE 47

Key exchange

  • Alice sends A = G, Bob sends B=G
  • Alice computes B
  • Bob computes B
  • Result is the same for both: G
  • Shared key established
slide-48
SLIDE 48

Securing wireless communications

  • We talked about the principles of symmetric and

asymmetric encryption

  • Data confidentiality is particularly important in

wireless communications, since the transmission medium is inherently broadcast (anyone can listen)

  • Wi-Fi is today the most popular wireless technology

and employed in a range of IoT scenarios.

  • How is Wi-Fi communication secured?
slide-49
SLIDE 49

Wired Equivalent Privacy (WEP)

  • Introduced in 1997 with the goal of providing

confidentiality comparable to that in wired networks

  • In essence WEP employs a stream cipher to hide

plaintext information. Key idea:

  • Each bit of the message is XOR-ed with a bit of a

pseudorandom stream, called keystream

  • Keystream generated using shift registers initialised with a

random seed

  • Vulnerable to attacks if the same seed used twice
  • Keystream obtained by concatenating 40/104-bit key with 24-

bit initialisation vector (IV)

  • CRC-32 used for integrity check
slide-50
SLIDE 50

WEP’s weakness

  • IVs transmitted in plain text (to avoid repetitions)
  • With 24-bit IVs, repetitions do not occur that often

(attacks by passively sniffing packets take long)

  • ARP request attack – artificially generate responses that

help gathering IVs fast – can crack the key in minutes.

slide-51
SLIDE 51

Solutions?

  • Implement an additional layer of security on top of

the link layer (IPsec, HTTPS, etc.) where possible

  • In 2013, IEEE proposed an amendment to the

standard (802.11i) that defined Wi-Fi Protected Access (WPA) to replace WEP

  • Key idea:
  • Continue using the RC4 cipher, but
  • Employ a per-packet key using the Temporal Key Integrity

Protocol (TKIP)

  • Combine the IV with a secret root key and add a rekeying

mechanism (change key periodically)

slide-52
SLIDE 52

Problems with TKIP

  • TKIP implements a 64-bit Message Integrity Check

(MIC) – this is exploited by guessing ~14 unknown bytes of ARP packets

  • TKIP performs rekeying if two incorrect MIC codes

received within 60 seconds.

  • Attack still feasible within less than 20 minutes.
slide-53
SLIDE 53

WPA2

  • RC4 replaced with AES block ciphering
  • Initial authentication performed via
  • Pre-shared key (PSK) or
  • Using the Extensible Authentication Protocol (EAP) –

Enterprise security, requires an authentication server

  • After authentication, a Pairwise Master Key (PMK) is

generated, which is derived from a password that is cryptographically hashed.

slide-54
SLIDE 54

WPA2 – Four-way handshake

slide-55
SLIDE 55

The WPA2 KRACK exploit

  • Client and AP prove to each other that they know

the PMK, without disclosing it.

  • WPA2 mathematically proven safe.
  • Used without issues for almost 15years.
  • Until the end of 2017 when the KRACK attack was

published - Linux and Android susceptible.

  • Flaw: Client reinstalls an all-zero encryption key

when the third message is received a second time.

  • A man-in-the-middle needs to be set-up for this
slide-56
SLIDE 56

WPA3

  • KRACK fixed in WPA3
  • Additional features
  • Opportunistic Wireless Encryption – Replaces PSK with

Diffie-Hellman key exchange, specific for each device

  • Simultaneous Authentication of Equals (SAE) – more

secure pre-shared keys, yet easy to use (weak passwords)

  • Secure connection for devices with limited UI (e.g.

without displays) - IoT

  • 192-bit encryption in enterprise settings
  • Forward secrecy
slide-57
SLIDE 57

Bluetooth Secure Simple Pairing

  • Purpose: secure a connection between two

Bluetooth devices

  • Five different phases (all but phase 2 are the same

for all protocol variants):

  • Phase 1: Public key exchange
  • Phase 2: Authentication Stage 1
  • Phase 3: Authentication Stage 2
  • Phase 4: Link key calculation
  • Phase 5: LMP Authentication and Encryption
slide-58
SLIDE 58

Phase1: Public key exchange

  • Each device generates its own Elliptic Curve Diffie-

Hellman (ECDH) public-private key pair

  • Initiating device sends public key to receiving

device, which in turn responds with its own public key

  • Both compute the same shared key
  • A device may choose to discard its public-private key

pair and generate a new one after some time

slide-59
SLIDE 59

Phase 2: Authentication stage 1

  • Three separate protocols: Numeric comparison, out
  • f band, passkey entry
  • “Just works” works exactly like the numeric

comparison but does not require user interaction

  • Numeric comparison not perfect: active MITM

attacks can succeed with probability 10-6

  • If no MITM at pairing, the Link Key generated later is

computationally secure

slide-60
SLIDE 60

Authentication stage 1: Numeric comparison

  • Each devices generates a pseudo-random 128-bit

nonce (protects from replay attacks)

  • Responding device computes a commitment (one-

way function of public keys and its nonce)

  • Devices exchange nonces
  • Receiving device sends commitment
  • Initiating device computes the same commitment;

aborts of the two commitments do not match.

slide-61
SLIDE 61

Phase 2: Authentication stage 1

slide-62
SLIDE 62

Phase 3: Authentication stage 2

  • Confirming that both devices have successfully

completed the exchange

  • Confirmation values computed as functions of

DHkey, nonces, addresses, IO capabilities

slide-63
SLIDE 63

Phase 4: Link Key calculation

  • Each devices computes independently Long Term

Key (LTK) based on the shared secret key, nonces exchanged, and device addresses used during paring

slide-64
SLIDE 64

Phase 5: LMP authentication and encryption

  • Consists of authentication and generation of

encryption key, to be used for ensuring data confidentiality during communication

  • This is the same as the final steps in legacy pairing
  • AES-128 encryption used for communication
slide-65
SLIDE 65