Hardwear.io – The Hague, Netherlands – September, 22nd 2016 Renaud Lifchitz ([email protected]) Security review of LoRaWAN networks

Outline Introduction to LoRaWAN networks & protocol Protocol attacks Implementation weaknesses Hardware attacks on node devices P. 2 Security review of LoRaWAN networks - Digital Security

Speaker's bio French senior security engineer Main activities:  Penetration testing & security audits  Security research  Security trainings Main interests:  Security of protocols (authentication, cryptography, information leakage, reverse engineering...)  Number theory (integer factorization, primality testing, ...) Security review of LoRaWAN networks - Digital Security P. 3

About Digital Security Company founded in 2015 by a group of experts with the support of Econocom Group Provides advanced services in security audit, consulting and support Our expertise combine traditional security for infrastructure and application, and skills oriented to the ecosystem of connected objects Has created the CERT-UBIK, first European CERT™ specialized on IoT security (OSIDO monitoring service) Has a laboratory for studying new technologies, protocols and specific operating systems Security review of LoRaWAN networks - Digital Security P. 4

Introduction to LoRaWAN networks & protocol

What is LoRa/LoRaWAN? LoRa is a proprietary radio modulation/protocol by Semtech LoRa is a LOng RAnge Low-Power (LPWAN) protocol LoRaWAN is the network stack designed by LoRa Alliance Current main competitor is Sigfox Introduction to LoRaWAN networks & protocol P. 6 Security review of LoRaWAN networks - Digital Security Extract from « Orange LoRa Device Developer Guide »

LoRaWAN benefits Encryption and signature using cryptography Very good sensitivity Bidirectional Works indoor, underground (2-3 floors), in elevators Allows geolocation (< 100m precision) LoRaWAN specification: https://www.lora-alliance.org/portals/0/specs/LoRaWAN%20Specification%201R0.pdf Introduction to LoRaWAN networks & protocol P. 7 Security review of LoRaWAN networks - Digital Security

LoRaWAN key use cases Introduction to LoRaWAN networks & protocol P. 8 Security review of LoRaWAN networks - Digital Security Extract from « Orange LoRa Device Developer Guide »

Some LoRaWAN networks Commercial networks:  KPN (The Netherlands)  Orange and Bouygues Telecom (France) Community networks:  TheThingsNetwork (international) Many private networks Introduction to LoRaWAN networks & protocol P. 9 Security review of LoRaWAN networks - Digital Security

Some LoRaWAN networks Interestings TheThingsNetwork stats we’ve collected Introduction to LoRaWAN networks & protocol P. 10 Security review of LoRaWAN networks - Digital Security Dashboard made from public data (previous staging infrastructure)

Some LoRaWAN networks Interestings TheThingsNetwork stats we’ve collected Introduction to LoRaWAN networks & protocol P. 11 Security review of LoRaWAN networks - Digital Security Dashboard made from public data (previous staging infrastructure)

LoRaWAN architecture Introduction to LoRaWAN networks & protocol P. 12 Security review of LoRaWAN networks - Digital Security Extract from a Semtech whitepaper

LoRa radio protocol Proprietary modulation using a spread spectrum technique called Chirp Spread Spectrum (CSS) and it uses forward error coding in combination with whitening and interleaving Introduction to LoRaWAN networks & protocol P. 13 Security review of LoRaWAN networks - Digital Security Extract from https://revspace.nl/DecodingLora

LoRaWAN protocol stack Class A devices are the most used nowadays Introduction to LoRaWAN networks & protocol P. 14 Security review of LoRaWAN networks - Digital Security Extract from « LoRa Alliance - a technical overview of LoRa and LoRaWAN »

The join procedure 2 ways to authenticate and join a network:  ABP (Activation By Personalization): ↪ Encryption key (AppSKey) and authentication key (NwkSKey) are pre-shared  OTAA (Over The Air Activation): ↪ Encryption key (AppSKey) and authentication key (NwkSKey) are derived from a pre-shared AppKey during the join procedure Introduction to LoRaWAN networks & protocol P. 15 Security review of LoRaWAN networks - Digital Security

Cryptography Every message is encrypted using a keystream generated from AES-128 and AppSKey Then the message is signed using AES-128 CMAC and NwkSKey Introduction to LoRaWAN networks & protocol P. 16 Security review of LoRaWAN networks - Digital Security Extract from « Libelium Waspmote LoRaWAN Networking Guide »

Protocol attacks

Attacks on encryption – message length Contrary to popular belief, LoRaWAN messages are *NOT* encrypted with AES! (only the « join accept » message) Numbered blocks are encrypted using AES-128 with AppSKey and act as a keystream Keystream is just XORed with plaintext message Original message size is kept after encryption Headers (typically 9 bytes) and MIC (4 bytes) are added to the encrypted payload so: Original message size = LoRaWAN frame size – 13 It becomes easy to distinguish some plaintext messages! Protocol attacks P. 18 Security review of LoRaWAN networks - Digital Security Plaintext message sizes are distinguishable

Attacks on encryption – message length Example – Will you be able to find the correct messages? Protocol attacks P. 19 Security review of LoRaWAN networks - Digital Security {"rxpk":[{"tmst":359313388,"time":"2016-09- 20T20:12:00.934587Z","chan":6,"rfch":0,"freq":8 67.700000,"stat":1,"modu":"LORA","datr":"SF7BW1 25","codr":"4/5","lsnr":10.0,"rssi":- 15,"size":21,"data":"QIu9zB2AAAAEnXwVdJyRCdly5X sQ"}]} {"rxpk":[{"tmst":396396091,"time":"2016-09- 20T20:12:38.018627Z","chan":1,"rfch":1,"freq":8 68.300000,"stat":1,"modu":"LORA","datr":"SF7BW1 25","codr":"4/5","lsnr":9.8,"rssi":- 17,"size":22,"data":"QIu9zB2AAQAEbZ3czyXUQGNvGU quiQ=="}]} It’s cold It’s hot

Attacks on encryption - keystream Keystream reuse may occur:  If node is configured in ABP mode and device is somehow reset (we don’t care about network rejection in that case)  Or if node is configured in OTAA mode and a past AppSKey appears again. By the birthday attack, we have 50% chance of a DevNonce collision in every batch of 2. log 2 . 216 ~ 300 DevNonce, we have 50% chance of a DevNonce+AppNonce collision in every batch of 2. log 2 . 240 ~ 1234600 DevNonce+AppNonce and we have 50% chance of a DevNonce+AppNonce collision in every batch of 2. log 2 . (11 ∗ 224) ~ 16000 DevNonce+AppNonce if device is controlled by the attacker (forced DevNonce) Protocol attacks P. 20 Security review of LoRaWAN networks - Digital Security

Attacks on encryption - keystream Keystream reuse may occur:  In the OTAA case, suppose a device reset+join takes about 5 seconds  If the attacker can force DevNonce (requires physical access to the device), he can cause the reuse after about 22 hours on average  Otherwise the attack will take at least about 71 days (depends on device configuration)  In all cases, sequence numbers must match  Duty cycle is absolutely not enforced here  Note that if AppSKey occurs again, NwkSKey will also occur with very high probability: messages with their MIC will be valid again! Protocol attacks P. 21 Security review of LoRaWAN networks - Digital Security Replay attacks are possible under assumptions Keystream reuse can occur in ABP or OTAA (mostly under attack)

Attacks on encryption - keystream Keystream reuse may occur - precomputed table useful for cracking: Protocol attacks P. 22 Security review of LoRaWAN networks - Digital Security XOR of corresponding encrypted bytes Possibilities for plaintext ASCII digits 02 0 and 2, 1 and 3, 4 and 6, 5 and 7 03 0 and 3, 1 and 2, 4 and 7, 5 and 6 00 all pairs of equal digits 01 0 and 1, 2 and 3, 4 and 5, 6 and 7, 8 and 9 06 0 and 6, 1 and 7, 2 and 4, 3 and 5 07 0 and 7, 1 and 6, 2 and 5, 3 and 4 04 0 and 4, 1 and 5, 2 and 6, 3 and 7 05 0 and 5, 1 and 4, 2 and 7, 3 and 6 08 0 and 8, 1 and 9 09 0 and 9, 1 and 8 0b 2 and 9, 3 and 8 0c 4 and 8, 5 and 9 0a 2 and 8, 3 and 9 0f 6 and 9, 7 and 8 0d 4 and 9, 5 and 8 0e 6 and 8, 7 and 9

Attacks on encryption – keystream Example Suppose we have sniffed the following two ABP encrypted messages (Python snippet): We compute their XOR: We look at the non-zero bytes (ignoring the final MIC) in the pre-computed table and find that the plaintext digits are 4 and 9, or 5 and 8. Indeed the plaintext messages were: Protocol attacks P. 23 Security review of LoRaWAN networks - Digital Security >>> m1='QBlGSyUAAAAByWG1qEHTwryLoLv8wygR5qYygpCLCw=='.decode('base64') >>> m2='QBlGSyUAAAAByWG1qEHTwryLoLv8wygR5qsya5tMuw=='.decode('base64') >>> ' '.join(['%02x' % (ord(m1[i])^ord(m2[i])) for i in range(len(m1))]) '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0d 00 e9 0b c7 b0' {"temperature":24} {"temperature":29}

Attacks on encryption – keystream Conversely, if the attacker knows the plaintext of one message, he can compute the keystream and decrypt the other message Protocol attacks P. 24 Security review of LoRaWAN networks - Digital Security A chosen-plaintext attacks is possible under assumptions Two known-plaintext attacks are possible under assumptions

Attacks on join requests LoRaWAN specification: « DevNonce is a random value. For each end-device, the network server keeps track of a certain number of DevNonce values used by the end-device in the past, and ignores join requests with any of these DevNonce values from that end- device. » Number of DevNonce stored by network server is unspecified Join requests *may* be vulnerable to replay attacks after severeral joins (more details in implementation attacks) Protocol attacks P. 25 Security review of LoRaWAN networks - Digital Security

Attacks on gateways No standard protocol for gateway to network server communications in LoRaWAN specifications Semtech published « Gateway to Server Interface Definition » v1.0 (July 2015):  Plaintext UDP protocol, usually on port 1700 or 1680  Encrypted LoRaWAN messages are sent in JSON  Protocol doesn’t authenticate gateways! Gateway spoofing is easy, requires only the knowledge of a gateway EUI (public on many networks):  1) Spoofing prevents the legitimate gateway from receiving messages from network server => all downlink messages are blocked  2) Spoofing allows sniffing of all downlink messages from this gateway Protocol attacks P. 26 Security review of LoRaWAN networks - Digital Security Semtech network protocol is vulnerable to spoofing, sniffing and denial-of-service

Implementation weaknesses

Tools – our LoRaWAN framework We have developed a (private) full LoRaWAN security framework that includes:  Tools to capture OTA and network LoRaWAN messages  A LoRaWAN dissector  Crypto implementations  Attack tools: packet injection, offline key bruteforcer, gateway &node spoofing… Implementation weaknesses P. 28 Security review of LoRaWAN networks - Digital Security

Tools – our LoRaWAN framework Implementation weaknesses P. 29 Security review of LoRaWAN networks - Digital Security Offline frame decryption using join handshake and AppKey

Infrastructure security Infrastructure security is globally not good:  We’ve bought a gateway where you can’t set a password on the admin web interface…  A lot of open systems can be easily found on the Internet: ↪ Many MQTT network servers of a nation-wide LoRaWAN operator with customer messages ↪ Many LoRaWAN applications and parts of private networks ↪ Many home automation systems Implementation weaknesses P. 30 Security review of LoRaWAN networks - Digital Security

Attacks on join requests Replay attacks are possible:  As we’ve seen, the number of DevNonce to be stored is unspecified  We checked 2 open source LoRaWAN servers, both store only the last 10 DevNonce: ↪ brocaar/loraserver (https://docs.loraserver.io/loraserver/): ↪ TheThingsNetwork server (https://github.com/TheThingsNetwork/ttn): Implementation weaknesses P. 31 Security review of LoRaWAN networks - Digital Security Deauthentication attacks are possible after a while Join requests can be replayed after a while (spoofing) $ grep -r UsedDevNonceCount . ./models/node.go:// UsedDevNonceCount is the number of used dev-nonces to track. ./models/node.go:const UsedDevNonceCount = 10 ./core/components/broker/broker.go: MaxDevNonces uint ./core/components/broker/broker.go: MaxDevNonces: 10, ./core/components/broker/broker.go: if uint(len(nonces.DevNonces)) > b.MaxDevNonces {

Attacks on join requests DevNonce random generation is often weak:  IBM’s LoRaWAN implementation: LMIC version 1.6: ↪ http://www.research.ibm.com/labs/zurich/ics/lrsc/lmic.html ↪ Used in most Arduino-compatible nodes Implementation weaknesses P. 32 Security review of LoRaWAN networks - Digital Security // seed 15-byte randomness via noise rssi rxlora(RXMODE_RSSI); while( (readReg(RegOpMode) & OPMODE_MASK) != OPMODE_RX ); // continuous rx for(int i=1; i<16; i++) { for(int j=0; j<8; j++) { u1_t b; // wait for two non-identical subsequent least-significant bits while( (b = readReg(LORARegRssiWideband) & 0x01) == (readReg(LORARegRssiWideband) & 0x01) ); randbuf[i] = (randbuf[i] << 1) | b; } } randbuf[0] = 16; // set initial index

Attacks on join requests DevNonce random generation is often weak:  We’ve collected more than 220,000 DevNonce from a nation-wide LoRaWAN operator  We tested several batches of 20,000 nonce  Nearly all FIPS randomness tests failed!  Globally, too many « 1 » bits in the number Implementation weaknesses P. 33 Security review of LoRaWAN networks - Digital Security DevNonce generation is not random enough on nodes

Attacks on join requests DevNonce random generation is often weak: FIPS monobit test Implementation weaknesses P. 34 Security review of LoRaWAN networks - Digital Security

Attacks on join requests DevNonce random generation is often weak: Character count analysis Implementation weaknesses P. 35 Security review of LoRaWAN networks - Digital Security

Attacks on join requests DevNonce random generation is often weak: Character transition analysis Implementation weaknesses P. 36 Security review of LoRaWAN networks - Digital Security

Attacks on encryption Keys (128 bits) are sometimes weaks on small/test networks:  SemTech (http://iot.semtech.com/) & TheThingsNetwork default key: 2B7E151628AED2A6ABF7158809CF4F3C  repeated byte: ex.: D8D8D8D8D8D8D8D8D8D8D8D8D8D8D8D8  increasing bytes: ex.: 0102030405060708090A0B0C0D0E0F10  based on AppEUI and/or DevEUI (which are sent cleartext during join requests) Implementation weaknesses P. 37 Security review of LoRaWAN networks - Digital Security

Hardware attacks on node devices

Badly designed LoRaWAN devices Some devices allow direct reading of private keys they store using their builtin commands: Hardware attacks on node devices P. 39 Security review of LoRaWAN networks - Digital Security $ miniterm.py -e -b 19200 -p /dev/ttyUSB0 --- Miniterm on /dev/ttyUSB0: 19200,8,N,1 --- --- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H --- +++ ARM-LORAWAN - Welcome in setup mode - ATLO O000=B0 RAM B0 EEP O001=00 RAM 00 EEP O002=00 RAM 00 EEP (...) O068=55 RAM 55 EEP O069=     O070=        O071=        O072=               O073=116B8E6584CF23B7949D8534D54CB176 O074=0F281E8DBD56E5E202541E9B24ED1754 O075=00 RAM 00 EEP O076=00 RAM 00 EEP (...) <- DevAddr <- DevEUI <- AppEUI <- AppKey <- NwkSKey <- AppSKey

Debug ports Several debug ports on most devices:  Serial port (UART)  SWD  JTAG They often allow RAM/Flash dumps where sensitive keys are stored: AppKey/AppSKey/NwkSKey Key candidates can be quickly tested offline using bruteforce Hardware attacks on node devices P. 40 Security review of LoRaWAN networks - Digital Security

Side-Channel Analysis Using SCA and monitoring power consumption of an Arduino-compatible microcontroller during only 30- 50 encryptions, we were able to recover an AES-128 key We have used a ChipWhisperer-Lite and CPA (Correlation Power Analysis) Hardware attacks on node devices P. 41 Security review of LoRaWAN networks - Digital Security Naive AES implementations can easily be broken using SCA

Conclusion - general recommendations Prefer OTAA over ABP mode Actively monitor your gateways for active attacks (for private networks) Enforce the duty cycle Protect your infrastructure (no default configuration, strong passwords) Use binary messages instead of JSON Use constant length messages (use padding if necessary) Use different keys on every node Don’t use devices where private keys can be read using builtin commands If possible, use devices with a Secure Element For the best specific recommendations for your project, contact us!  P. 42 Security review of LoRaWAN networks - Digital Security

Thanks! Questions? IoT Security Contact: [email protected] [email protected] P. 43 Security review of LoRaWAN networks - Digital Security