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
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
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 »
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
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
LoRaWAN networks & protocol P. 10 Security review of LoRaWAN networks - Digital Security Dashboard made from public data (previous staging infrastructure)
LoRaWAN networks & protocol P. 11 Security review of LoRaWAN networks - Digital Security Dashboard made from public data (previous staging infrastructure)
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
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 »
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
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 »
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
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
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
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)
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
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}
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
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
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
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
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
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 {
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
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
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
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
rlifchitz
cfiken
bo0om
beeeee
hiroki13
eumesy
rkrokee
kikuzo
jriely
shunk031
ritsu2891
ks91
nk35jk
iamctodd
chriscoyier
tanoku
mthomps
schacon
bryan
paulrobertlloyd
marktimemedia
reverentgeek
smashingmag
