SLIDE 1 IoT Security
Image: xkcd
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 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 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 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 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 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 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
ENISA IoT threat taxonomy (Nov. 2017)
Consistent with the threat taxonomy released in Jan 2016, but easier to navigate and IoT focused
SLIDE 10
ENISA IoT threat taxonomy (Nov. 2017)
SLIDE 11
IoT threats impact (ENISA)
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 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 Example – fitness tracking systems
wristband user smartphone wireless router Internet cloud server BLE Wi-Fi
SLIDE 15 Example – fitness tracking systems
wristband user smartphone wireless router Internet cloud server BLE Wi-Fi Packet sniffing, DoS, code injection
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 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 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 How to mitigate such a multitude
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
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 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 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 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 Code signing
*Cisco
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 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 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 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 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 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
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
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
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
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
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 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
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 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 Asymmetric encryption
*The Globus Toolkit 4 Programmer's Tutorial
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 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
RSA operation
Encryption: c = me (mod n) Decryption: cd = (me)d = m (mod n)
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
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 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 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 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 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 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 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 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 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 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
WPA2 – Four-way handshake
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 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 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 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 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 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
Phase 2: Authentication stage 1
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 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 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