Breaking the signature that makes a path checkable¶

Attack pattern¶

BGPsec makes the AS path verifiable by having every autonomous system on it sign what it adds, using ECDSA over P-256. That turns a forged path from something indistinguishable into something detectable, and moves the work from the announcement to the signature. Three routes lead back out. Break the mathematics, which for ECDSA means the nonce rather than the curve, since a handful of signatures generated with a biased or repeated value give up the private key to lattice reduction. Take the key instead, from a hardware module, a cloud key store, or the generation process that produced it. Or leave the cryptography alone and go after the code that checks it, where a parser difference, a short-circuited verification path or a time-of-check gap costs nothing in mathematics at all.

1. Compromise BGPsec Validation [OR]

    1.1 Exploit Cryptographic Weaknesses [OR]

        1.1.1 Algorithm Vulnerabilities [OR]
            1.1.1.1 ECDSA with biased nonces (key recovery)

        1.1.2 Implementation Flaws [OR]
            1.1.2.1 Non-constant-time implementations (timing attacks)
            1.1.2.2 Memory corruption in crypto libraries (CVE-2022-3602)
            1.1.2.3 Side-channel leaks (Minerva, Power analysis)

        1.1.3 Post-Quantum Threats [OR]
            1.1.3.1 Trust now, forge later (retroactive path forgery)
            1.1.3.2 Weak hybrid transition implementations
            1.1.3.3 Shor's algorithm preparation attacks

    1.2 Key Management Compromise [OR]

        1.2.1 Private Key Theft [OR]
            1.2.1.1 HSM vulnerabilities
            1.2.1.2 Supply chain backdoors in key generation
            1.2.1.3 Cloud HSM misconfigurations

        1.2.2 Key Rotation Failures [OR]
            1.2.2.1 Delayed key revocation propagation
            1.2.2.2 Weak key rotation policies
            1.2.2.3 Compromised key history retention

        1.2.3 Certificate Validation Bypass [OR]
            1.2.3.1 Rogue CA compromise for BGPsec certificates
            1.2.3.2 Trust anchor manipulation

    1.3 Protocol Implementation Attacks [OR]

        1.3.1 BGPsec Stack Vulnerabilities [OR]
            1.3.1.1 Memory corruption in BGPsec implementations
            1.3.1.2 Resource exhaustion attacks
            1.3.1.3 Parser differential attacks

        1.3.2 Validation Bypass [OR]
            1.3.2.1 Signature verification short-circuiting
            1.3.2.2 Cache poisoning attacks
            1.3.2.3 Time-of-check-time-of-use (TOCTOU) flaws

        1.3.3 Downgrade Attacks [OR]
            1.3.3.1 BGPsec capability negotiation manipulation
            1.3.3.2 Fallback to unsigned BGP sessions
            1.3.3.3 Version negotiation exploits

The signature is not the check¶

ECDSA rarely fails at the curve. It fails at the nonce, where a bias or a repeat across a few signatures hands over the private key to lattice reduction.
A valid signature proves who relayed the route, not whether relaying it was permitted. BGPsec authenticates the path and says nothing about route leaks, which is the gap ASPA was proposed to fill.
Validation runs per hop. A long path costs one verification per autonomous system, which puts the expense on the receiver and leaves it cheap for the announcer.
Implementation is a wider surface than the algorithm. Parser differentials, short-circuited verification and time-of-check gaps each bypass the mathematics without engaging it.
The X.509 handling underneath is shared code. A certificate parsing flaw of the CVE-2022-3602 kind arrives in the routing stack from outside the routing world entirely.
What a future break exploits is the published key rather than any recorded signature. Routing announcements are withdrawn and gone; the public key is served continuously.