Tag: cryptography

  • Flipper Zero, part 3: Sub-GHz remotes, rolling codes and how gates should be built

    Flipper Zero, part 3: Sub-GHz remotes, rolling codes and how gates should be built

    Part 3 of 5 in the Flipper Zero series. Part 1: what it actually is and what it can’t do. Part 2: why so many office badges are weaker than they look.

    Garage doors, gates, car fobs, doorbells and cheap alarm sensors all talk on a handful of license-free bands, mostly around 315, 433.92, 868 and 915 MHz depending on where you live. The Flipper Zero has a CC1101 transceiver that covers 300 to 348, 387 to 464 and 779 to 928 MHz, with regional limits on where it will transmit. That makes it a convenient way to look at your own remotes and ask whether the thing guarding your driveway was designed by someone who had met an attacker.

    Same rules as the earlier parts: my own device, my own remotes, and a defender’s goal. Transmitting captured codes at a gate or car you do not own is illegal in most places, and the receiver you are testing may belong to a landlord or an employer. Get permission first.

    What the Flipper shows you

    The Sub-GHz menu has Read, Read RAW, Saved and Add Manually. Read tries to decode a signal against the protocols it knows and prints the frequency, modulation and the bits. Read RAW records the pulse timing without interpreting it.

    The first photo is my own Flipper’s main menu with Sub-GHz selected, and the second is its Sub-GHz submenu.

    Flipper Zero main menu with Sub-GHz highlighted
    Flipper Zero Sub-GHz submenu: Read, Read RAW, Saved, Add Manually

    Press a cheap fixed-code remote near it and the Flipper will show you the same bits every time. Press a rolling code remote and the bits change on every press. Seeing that difference on your own remote takes about ten seconds and is a better lesson than any slide.

    Fixed codes: nothing to defend

    Old remotes with DIP switches, or the cheapest 433 MHz clones, send the same code on every press. Anyone who hears it once can send it forever. There is no cryptography to attack, which is the whole problem. If your gate still uses one, the fix is to replace the receiver and remotes. Nothing you can configure makes a fixed code safe.

    Rolling codes: what they actually are

    A rolling code remote sends a serial number and a counter, protected so that a receiver can check the counter has moved forward. The best known design is Microchip’s KeeLoq. It uses a 32 bit block cipher with a 64 bit key and 528 rounds. The hopping part of the message carries a 16 bit synchronisation counter, and the serial number goes out in the clear next to it. In the common learning schemes the per-remote key is derived from the serial number and a manufacturer key.

    That last detail is where the trouble started. Several groups published cryptanalysis of KeeLoq in 2007 and 2008, and in 2008 Eisenbarth and colleagues presented “On the Power of Power Analysis in the Real World” at CRYPTO. They used power analysis on the receiver side to extract the manufacturer key. With that key, anyone who hears one transmission from a remote can compute its key from the serial number. That is a break of the whole product family, not of one gate.

    Receivers also have to tolerate lost presses. You pressed the button in your pocket twice, out of range, and the receiver has to accept counter 5 after seeing counter 2. So it accepts any value inside a look-ahead window. Here is a toy model of that logic. It is not KeeLoq, it uses HMAC-SHA256 truncated to 4 bytes, but the receiver behaviour is the same shape:

    import hmac, hashlib
    
    KEY = b"per-remote-secret"
    WINDOW = 16
    
    def code(counter):
        msg = counter.to_bytes(4, "big")
        return hmac.new(KEY, msg, hashlib.sha256).digest()[:4].hex()
    
    class CounterReceiver:
        def __init__(self):
            self.last = 0
        def press(self, c):
            for n in range(self.last + 1, self.last + 1 + WINDOW):
                if hmac.compare_digest(code(n), c):
                    self.last = n
                    return f"OPEN (counter {n})"
            return "rejected"

    Jam and capture

    Samy Kamkar showed the practical weakness at DEF CON 23 in 2015 with a device he called RollJam. The attacker jams the receiver and records the owner’s press at the same time. The owner presses again, the attacker jams and records that too, but this time releases the earlier code to the receiver, so the door opens and nobody suspects anything. The attacker now holds a valid code the receiver has never seen.

    The diagram below compares the two receiver designs side by side.

    Sequence diagram comparing a counter-only receiver, where jammed and recorded codes open the gate twice, with a challenge-response receiver, where a recorded answer fails against a fresh nonce. Annotation boxes added for explanation.

    The key point is that a counter-only receiver has no idea when a code was made. A code from yesterday is as good as one from a second ago, as long as the counter has not passed it. I ran the toy model through the scenario and rendered the real output below. The jammed presses are generated by my script, so this is a simulation of the logic, not a capture of any real remote.

    Terminal output of the toy rolling code receiver showing a replay rejected, a jam-and-capture attack succeeding twice, and a challenge-response receiver rejecting a captured answer

    Note the third line of the middle block. The receiver accepts the stored second code long after the owner walked off. Once the stored code is used, replaying it fails, so the attack is a one-shot, but one shot is enough to open a gate.

    Counter windows have caused real vulnerabilities too. CVE-2021-46145 covers the Honda Civic 2012 key fob, where the rolling code does not expire and the counter resynchronisation can be abused to replay unlock commands. CVE-2022-27254 is a worse case on the 2018 Civic, where the remote sends the same signal for every unlock request, so it was never rolling at all.

    How a gate should be built

    If I were specifying a new gate or garage opener, the list would be short.

    First, the receiver should reject codes older than a few seconds, or use challenge-response. In the last block of the demo the receiver sends a random nonce and the remote answers with an HMAC of it. A captured answer fails against the next nonce, so storing it gains nothing. This needs a two way radio, which costs a little more, and that is the price of getting rid of the stored-code attack.

    Second, use a modern authenticated protocol with a per-device key that is not derived from a shared manufacturer secret. AES-based systems exist. Ask the installer what the remote actually uses, and if the answer is “rolling code” with no name attached, treat that as a fixed code until proven otherwise.

    Third, keep the radio the weaker half of the system. A gate that opens on a single radio message should not also be the only barrier to something you care about. Put cameras on it, put a lock on the inner door, and do not rely on it to separate a vehicle from the street.

    Fourth, plan to replace the remotes. Lost ones should be removed from the receiver, not just forgotten, which means choosing a receiver that actually lets you delete individual remotes.

    Testing your own gear

    With the Flipper you can check three things on your own remote. Does Read decode it as a known protocol or leave you with raw pulses only? Do the bits change between presses? If they do not, you have a fixed code and a replacement project. And can you find the manufacturer and model on the receiver, so you can read its actual security claims rather than guessing?

    I would not go further than that on equipment I do not control.

    Part 4 moves to USB, keystroke injection from the Bad USB menu, and how to lock endpoints down.

    Other parts of the Flipper Zero series: part 1, part 2, part 3, part 4 (publishes Nov 5), part 5 (publishes Nov 6).

  • Why TLS 1.3 Handshakes Are Faster (And What Changed Under the Hood)

    Why TLS 1.3 Handshakes Are Faster (And What Changed Under the Hood)

    The 1-RTT handshake and what changed

    TLS 1.2 vs TLS 1.3 handshake sequence comparison

    TLS 1.3 (RFC 8446, finalized August 2018) isn’t a tuning pass on TLS 1.2. It’s a different protocol with the same name. The headline feature is a 1-RTT handshake instead of 2-RTT, but what I find more interesting is why that became possible: the designers deleted static RSA key exchange, deleted renegotiation, and made forward secrecy mandatory. This post walks through what changed on the wire.

    TLS 1.2’s 2-RTT problem

    A full TLS 1.2 handshake looks like this:

    Client                                               Server
      ClientHello  (cipher suites, supported groups, random) -->
                                                  <-- ServerHello (chosen cipher)
                                                  <-- Certificate
                                                  <-- ServerKeyExchange (if DHE/ECDHE)
                                                  <-- ServerHelloDone
      ClientKeyExchange -->
      [ChangeCipherSpec] -->
      Finished -->
                                                  <-- [ChangeCipherSpec]
                                                  <-- Finished
      Application Data <-->

    The client sends a hello, the server replies with everything needed to pin down the cipher and key exchange, and only then can the client respond with its key material and a Finished message. Application data doesn’t move until after that second round trip. On a connection with 80ms RTT to a distant CDN edge, that’s 160ms spent on negotiation before any application data moves.

    The root cause is ordering: the client has no idea which key exchange group or cipher the server will pick until ServerHello shows up, so it can’t send a key share in the first flight. So it has to wait.

    TLS 1.3’s fix: guess the group instead of negotiating it

    TLS 1.3 collapses the handshake by having the client guess which (EC)DHE group the server prefers and send a key share speculatively, right in the ClientHello:

    Client                                               Server
      ClientHello
        + key_share (e.g. x25519 public value)
        + supported_versions, signature_algorithms -->
                                                  <-- ServerHello
                                                        + key_share
                                                  <-- {EncryptedExtensions}
                                                  <-- {Certificate}
                                                  <-- {CertificateVerify}
                                                  <-- {Finished}
      {Finished} -->
      Application Data <-->                       <-- Application Data

    Everything in {} is encrypted. The server derives handshake traffic keys from its own ephemeral share plus the client’s key_share immediately after ClientHello arrives, so even the certificate exchange is now confidential. That closes a leak 1.2 had for years: certificates went over the wire in cleartext, so a passive eavesdropper could see which server you were talking to. Because the client already sent a key share up front, the server can finish the key agreement and start pushing encrypted application data in its very first response. Once the client has ServerHello and Finished, it can start sending data too, with no extra round trip to acknowledge anything. That’s the 1-RTT.

    If the client guesses wrong (rare these days since x25519 is close to universal), the server sends a HelloRetryRequest and you’re back to something like 2-RTT. That’s the exception, though, not what happens on a normal connection.

    You can watch this happen directly:

    $ curl -v --tlsv1.3 https://example.com 2>&1 | grep -i 'TLS\|SSL connection'
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    * TLSv1.3 (IN), TLS handshake, Server hello (2):
    * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
    * TLSv1.3 (IN), TLS handshake, Certificate (11):
    * TLSv1.3 (IN), TLS handshake, CV (15):
    * TLSv1.3 (IN), TLS handshake, Finished (20):
    * TLSv1.3 (OUT), TLS handshake, Finished (20):
    * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384

    Notice there’s no ServerKeyExchange or ClientKeyExchange message type anymore. Key exchange data rides inside the Hello messages as an extension (key_share) instead of being its own standalone handshake message.

    Static RSA key exchange is gone

    TLS 1.2 allowed TLS_RSA_WITH_* cipher suites, where the client just encrypts a premaster secret directly with the server’s RSA public key. There’s no Diffie-Hellman anywhere. It was fast (one asymmetric operation, no DHE math) but bad for confidentiality: if the server’s private key is ever compromised, subpoenaed, or pulled out via something like Heartbleed, every past session a passive adversary ever recorded becomes decryptable after the fact. There’s no forward secrecy, because one static key protects every session’s secret.

    RFC 8446 removes static RSA key exchange entirely. TLS 1.3 only supports (EC)DHE-based exchange, plus PSK for resumption, which I’ll get to below. Every handshake negotiates a fresh ephemeral key pair, so compromising the server’s long-term signing key lets an attacker impersonate the server from that point forward, but it buys them nothing against traffic captured earlier. You can no longer misconfigure forward secrecy away with a cipher-suite setting, because the protocol always provides it.

    Renegotiation is gone too. TLS 1.2’s renegotiation, re-running the handshake mid-connection to rotate keys or ask for a client cert, was the root cause of CVE-2009-3555, a plaintext-injection bug that needed the RFC 5746 patch as a partial band-aid. TLS 1.3 replaces that general-purpose “redo the whole handshake” mechanism with two narrower ones: post-handshake authentication (a CertificateRequest sent after the handshake, for mTLS-style client cert checks) and a dedicated KeyUpdate message for rotating keys.

    0-RTT resumption trades replay protection for speed

    For repeat connections, TLS 1.3 offers 0-RTT via PSK resumption. The client reuses a session ticket from an earlier connection and sends encrypted application data in the very first flight, before the server has said a word back:

    Client                                               Server
      ClientHello + early_data + psk extension
      (encrypted with early_data_key)
      Application Data (0-RTT) -->
                                                  <-- ServerHello, ... Finished
      Application Data <-->

    That’s zero round trips of latency before data moves, which helps a mobile client reconnecting to a server it already knows. The catch is that 0-RTT data has no replay protection. The client sends it before the handshake finishes, specifically before the server’s Finished message, which is the thing that actually proves liveness and ties the exchange together. A network-positioned attacker can just capture that first flight and replay it verbatim. At that layer the server can’t tell a replay from a legitimate retransmission.

    RFC 8446 Section 8 doesn’t try to fix this cryptographically. It leaves the problem to the application: only use 0-RTT for idempotent requests (safe GETs, not POST /transfer-funds), and let servers implement their own anti-replay measures, such as single-use tickets or bounded replay caches. Those measures give back some of the latency win in exchange for safety. I’ve seen teams enable 0-RTT, forget the tradeoff, and get surprised when a retry storm double-charges something. Most production setups (NGINX, HAProxy, Cloudflare) either disable 0-RTT outside of static content or require the application to opt in per request.

    Checking your own setup

    If you’re terminating TLS yourself, not sitting behind a CDN, confirm your stack is actually negotiating 1.3 and not quietly falling back to 1.2 for compatibility reasons that stopped mattering years ago. Run openssl s_client -connect host:443 -tls1_3 and check for Protocol: TLSv1.3 in the output.

    Drop any RSA key-exchange cipher suites still sitting in your 1.2 fallback config. Those are the forward secrecy hole TLS 1.3 was designed to close.

    If you turn on 0-RTT, go audit which endpoints can actually receive early data. Most servers let you scope this. Default to none until you’ve confirmed an endpoint is idempotent rather than assuming it.

    TLS 1.3 is more than TLS 1.2 with a speed boost. Static RSA key exchange is gone, renegotiation is replaced by narrower mechanisms, and 0-RTT gives up replay protection for latency. Know which guarantees you’re giving up before you turn it on.