Sequential Aggregate Signatures with Lazy Verification for BGPsec

Kyle Brogle

Sharon Goldberg Boston University

Leo Reyzin

http://www.cs.bu.edu/~goldbe/papers/bgpsec-sigs.html
IBM Research, New York April 4, 2011

Princeton University

This Talk
Part I : BGPsec and Our Signature

Part 2: RSA based aggregate signatures RSA-based

Part 3: Crypto Proofs

How Secure is Internet Routing Today? (1)

I am Verizon
69.82.0.0/15 69 82 0 0/15

Verizon China Telecom The Internet London Internet Exchange g

UK ISP

How Secure is Internet Routing Today? (2)

April 2010 : China Telecom intercepts traffic

This packet is destined for Verizon. Verizon

I am Verizon
69.82.0.0/15 69 82 0 0/15

Verizon China telecom The Internet London Internet Exchange g

I am Verizon
69.82.0.0/15 69 82 0 0/15 (and 50k other networks)

UK ISP

BGP: The Internet Routing Protocol (1)

P th f fi Paths from A t Autonomous S t Systems (AS ) t IP prefixes (ASes) to are set up via the Border Gateway Protocol (BGP).
IBM, Prefix

BU IBM AT&T Local ISP Comcast

IBM, IBM Prefix Comcast, IBM, Prefix

BGP: The Internet Routing Protocol (2)

P th f fi Paths from A t Autonomous S t Systems (AS ) t IP prefixes (ASes) to are set up via the Border Gateway Protocol (BGP).
AT&T, IBM, Prefix

$
BU

IBM

AT&T Local ISP Comcast

$
BU Ranking: Local, Local IBM AT&T, IBM Local, Comcast, IBM

Local, Comcast, IBM, Prefix

Attacks on BGP: Announcing false paths

C tl h i Currently BGP h no mechanism t validate has to lid t correctness of paths in BGP announcements.
AT&T, IBM, Prefix

BU IBM AT&T Local ISP ISP Comcast

RPKI
BU Ranking Local, Local IBM AT&T, IBM Local, Comcast, IBM

Local, IBM, Prefix

Step 1 of defending against BGP Attacks: St f d f di i t Att k The RPKI that certifies mapping of IP Prefixes and PKs to Ases
Operators are actually deploying this now!

Defending Against Attacks with BGPsec

Step 2: BGPsec to certify correctness of AS level paths AS-level paths.
New design of this went to the IETF in Prague just last week.
Comcast: (IBM Prefix) (IBM, Local: BU: (Comcast, IBM, Prefix) ( (Local, Comcast, IBM, Prefix) , , , )

BU

IBM

AT&T

Local ISP Comcast

RPKI Comcast: (IBM, Prefix)
Comcast: (IBM Prefix) (IBM, Local: (Comcast, IBM, Prefix)

Technical Hurdles for BGPsec

36K AS ASes
( Many PKs)

300K IP prefixes ( Store many BGPsec msgs) Routers are resource constrained

Source: CAIDA http://www.caida.org/publications/posters/png/ascore-ipv4-ipv6.200902.poster.png

Digital Signatures for BGPsec: Desiderata

Challenge: Routers must maintain local cache of >36K keys secure and current 36K Challenge: Routers must process BGP R t t BGPsec announcements quickly, even when they are overloaded. overloaded Challenge: Routers must store BGPsec announcements for each prefix. Signing algorithm requires no knowledge of previous signers. Lazy Verification to defer verification until load permits or public keys are retrieved Aggregate signatures shorten length of signature chains

[BGR] RSA sequential aggregate signature w. lazy verification. (or, a randomized version of [Neven08])

[BGR11] Instantiation with RSA, SHA-1, and HMAC msgn-1 msgn g g 1 bit b1 ,b2 , ,bn-1 b1 ,b2 , ,bn nth signer r1 ,r2 , , rn 1 r1 ,r2 , , rn k, k SKn n-1 128 bits hn-1 xn-1 hn xn
256 bits 2048 bits

To Sign

1. rn = HMACk(msgn | xn-1 | hn-1) 2. 2 hn = hn-1 + H( PKn | msgn | rn | xn-1) 3. xn = RSA ( G(hn) + xn-1)
4. Remove 1st bit of xn and save it as bn

128 bits 256 bit bits 2048 bits

1 bits

Signer has a local (unshared) key k used to compute HMAC In our implementation: k=256 bits, and 2048 bit RSA H = SHA-256; HMAC uses SHA-256; G is MGF with SHA-256

For our target application of BGPsec

Comcast: (IBM, Prefix) Local: BU: (Comcast, IBM, Prefix) (Local, Comcast IBM, (Local Comcast, IBM Prefix)

Local ISP

The real competition is nothing fancy: Trivial RSA S Trivial ECDSA Both of which allow: 1) Lazy verification, 2) Sign without knowing others keys

Benchmarks and Performance Comparison

RSA 2048 RSA-2048
PKCS, SHA-256

BGR - RSA-2048 RSA 2048

SHA-256 and RSA exp 65537

ECDSA 256 ECDSA-256

exp 65537

Total Sig g Length Average Sig Length n = 3.5 Signing Time Verification Time

129*n n * 2048 bit 2048 + 256 + 129* bits

2n 2 * 256 bits bit 1792 bits 2.33 ms n*2.77 ms

7168 bits 11.8 ms n * 0.27 ms

2756 bits 11.9 ms n * 0.30 ms

Benchmarks computed using OpenSSL & (our implementation) on a laptop: 2GB Ram, Core i3 at 2.4GHz running Linux Ubuntu

Signature Lengths
25000

Average path length in BGP

20000

BitLength

15000

10000

RSA2048 RSA 2048 BGR2048 Weaker routers see longer ECDSA256 n => BGR more efficient

5000

0 1 2 3 4 5 6 7 8 9 10 ECDSA shorter n, path for small n

length

Verify Time
30 Average path length in BGP 25 T Time(m ms) 20 15 10 5 0 1 2 3 4 5 6 7 8 9 10 n, path length
Verify time of BGR looks just like basic RSA

RSA2048 RSA 2048 BGR2048 ECDSA256

This Talk
Part I : BGPsec and Our Signature

Part 2: RSA based aggregate signatures RSA-based

[BGLS-03] [LMRS-04] [Neven-08] [Our Scheme]

Part 3: Crypto Proofs

Aggregate Signatures
Can we compress multiple signatures to save space? Aggregate signature: [Boneh-Gentry-Lynn-Shacham 2003]

Signer 1 m1, sig1

Signer 2

Signer 3

m2, sig2 Aggregate

m3, sig3

AggSig attesting to all three statements at once

The Aggregate Signature Tradeoff

[BGLS] B Based on P i i d Pairings over Elli ti C Elliptic Curves
less standard assumptions

What about something like RSA or Discrete Log? All known constructions without pairings require:
signers to know each others keys have a prescribed order of operations some operations using other signers public keys

Sequential Aggregate Signatures: signers to go in order

Not a big problem for BGP, since they do this anyway

Full-Domain Hash RSA [Rivest Shamir Adleman [Rivest-Shamir-Adleman 78, Bellare-Rogaway 93] Bellare Rogaway
Hash function H (full RSA domain outputs; random oracle). Public key PK = (n, e). Secret key SK = (n, d). y ( , ) y ( , ) Steps of the Signer:

y = H (m) x = y d mod n
Steps of the Verifier: m

2048bit

2048bit

RSA1

y = H (m) ? e y = x mod n

? =

RSA

[Lysyanskaya-Micali-Reyzin-Shacham 04]: Sign

Steps of Signer 2:

Check that PK1 specifies a permutation Verify x1 using PK1, m1 y2 = 2 x1

2048bit 2048bit

2 = H (PK1, PK2, m1, m2)

d x2 = y2 2 mod n2 Steps of Signer 3:

Signer 1: PK1 g m1 H H

y1 y2 y3

RSA1 RSA1 RSA1

x1 x2 x3

PK1, PK2 m1 , m2 PK1, PK2, PK3 m1, m2, m3

2 3

Check that PK1, PK2 specify permutations Verify x2 using PK1, PK2, m1, m2

[Lysyanskaya-Micali-Reyzin-Shacham 04]: Verify

Verification Algorithm

Check that PK1, PK2,PK3 specify permutations

PK1 m1 PK1, PK2 m1 , m2 PK1, PK2, PK3 m1, m2, m3

? y1 H =
H H

RSA y2 y3 RSA RSA

x1 x2 x3

2 3

[Lysyanskaya-Micali-Reyzin-Shacham 04]: Issues

Steps of Signer 2:

Check that PK1 specifies a permutation Verify x1 using PK1, m1 2 = H (PK1, PK2, m1, m2)
d x2 = y2 2 mod n2 Steps of Signer 3:

Either proofs, or long verification exponents Prevents lazy verification ifi i Requires other signers PKs

y2 = 2 x1

Check that PK1, PK2 specify permutations Verify x2 using PK1, PK2, m1, m2

[LMRS] Fails under Lazy Verification. Suppose an adversary wants to attack Signer 2 Adversary knows Signer 2 wants to sign m2. But adversary wants to get a sig on bad-m2.
Adversary: PK1 m1 H H H H y1 RSA1 x1

PK1, PK2 m1 , m2 PK1, PK2 m1, bad-m2 Signer 2: PK1, PK2 g m1 , m2

2
bad-2

bad-x1 y2 RSA1 x2

Valid aggregate sig on (m1, bad-m2)

[Neven08]: Sign
No more certified TDP, but sig now has two components: (x, h). Hash function H (short outputs), G (full RSA domain outputs) Steps of Signer 2:

Verify (x1, h1) using PK1, m1 2 = H (PK1, PK2, x1, m1, m2) h1 h2=2 h1 PK1,PK2 y2 = G(h2) x1 m1, m2 H 2 G d2 mod n 256bit h x2 = y2 2 2
PK1, PK2, PK3 m1 , m2 , m3 Steps of Signer 3: H

x1

2048bit

y2

RSA1 S
2048bit

x2

h3

y3

RSA1

x3

Verify (x2, h2) using PK1, PK2, m1, m2

[Neven08]: Verify Signature has two components: (x3, h3)

PK1 m1 PK1,PK2 m1, m2

? =
h1 G

? =
x1 y2

RSA

h2 G

x2

RSA S

PK1, PK2, PK3 m1 , m2 , m3

h3 G

y3

RSA

x3

[Neven08]: Issues
No more certified TDP, but sig now has two components: (x, h). No certified TDP, Hash function H (short outputs), G (full RSA domain outputs) but still prevents Steps of Signer 2: lazy verification Requires other Only an artifact of signers PKs Nevens proof. We get rid of this!

Verify (x1, h1) using PK1, m1 2 = H (PK2, PKm2)1, m1, m2) 1 x1, 2, x h2=2 h1 y2 = G(h2) x1 d x2 = y2 2 mod n2

PK1,PK2 m1, m2

Can break lazy verification in a similar way: inject h1 2 bad-2 y j x1 h1 G

h2

y2

RSA1

x2

Our Signature Scheme Randomize hash. Sig has (x, h) an a randomness r per signer.
Hash function H (short outputs), G (full RSA domain outputs)

Steps of Signer 2: p g Lazy Verification Random r2 x1 h1 2 = H (PK2, r2, x1, m2) PK2 h2=2 h1 2 y2 m2 x2 H G RSA1 y2 = G(h2) x1 r2 256bit h2 2048bit 2048bit d2 x2 = y2 mod n2 PK3 3 y3 1
m3 r3 H

h3

RSA

x3

Signing depends only on your own public key! Signature grows (~128 bits / signer if r psuedorandom.)
27

Comparison of (Some) Aggregate Signatures

[BGLS 03] [BGLS-03] Assumption Non-Sequential? Uncertified TDP? Lazy Verify? Signature Length (bits) Pairings Yes N/A Yes 128 [LMRS 04] [LMRS-04]
RSA

[Neven 08] [Neven-08] RSA No Yes No 2048 + 256

[BGR 11] [BGR-11] RSA No Yes Yes 2048 + 256 + 128n

No No No 2048

Wins on all counts except for assumption

Wins on all counts except for sig length But best for our target app of BGPsec

This Talk
Part I : BGPsec and Our Signature

Part 2: RSA based aggregate signatures RSA-based

Part 3: Crypto Proofs

Randomized Full Domain Hash [LMRS-04] [Neven-08] Improved [Neven-08] [Our Scheme] [N 08] I d [N 08] [O S h ]

Proof Warm Up A: Randomized Full Domain Hash

RSA is claw free claw-free. m, r H is FDH Random Oracle. m,r, H-Query H y 1 x

Proof: If forger F succeeds we find a claw (x)=(y) succeeds,

Random y Set = (y) Random r, x Abort if already set Set = (x)

Hash Table m,r mr , y

Sign Query Sign-Query

m r, x

Unlikely if 2Length(r) > qH qS Forgery m*, r*, x* Find H-query H(m*, r*) = (y*) Return claw (x*, y*)

Proof Warm Up B: [LMRS-04] (1)

1, 2 m1 , m2 H

x1

y2

x2

Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x)= (y) i, mi Get xi-1 associated with i-1, mi-1 i H-Query If * Random xi i = i (xi) xi-1 If i = * * Random zi i = * (zi) xi-1
i

Hash Table i, mi 1, xi,

Sign-Query

Forgery

Proof Warm Up B: [LMRS-04] (2A)

1, 2 m1 , m2 H

x1

y2

x2

Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x)= (y) i, mi Get xi-1 associated with i-1, mi-1 i H-Query If * Random xi i = i (xi) xi-1 Sign-Query i, mi, xi-1 xi
i

Hash Table i, mi 1, xi,

Verify xi-1 Verify i are permutations Random xi i = i (xi) xi-1

Forgery

Proof Warm Up B: [LMRS-04] (2B)

1, 2 m1 , m2 H

x1

y2

x2

Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x)= (y) i, mi Get xi-1 associated with i-1, mi-1 i H-Query If * There is only one xi-1 for each i-1, mi-1 Sign-Query i, mi, xi-1 xi Random xi i = i (xi) xi-1
i

Hash Table i, mi 1, xi,

So that F cant set i to the wrong value on an earlier H-Query Forgery

Verify xi-1 Verify i are permutations Random xi i = i (xi) xi-1

Proof Warm Up B: [LMRS-04] (3)

1, 2 m1 , m2 H

x1

y2

x2

Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x)= (y) i, mi Get xi-1 associated with i-1, mi-1 i H-Query If = * Random zi i = * (zi) xi-1 Sign-Query
i

Hash Table i, mi 1, xi,

Forgery

*, m*i, xi

Get zi, xii-1 i associated with i, mi 1 Return claw (xi, zi) because * (zi) = i xi-1= i (xi)

Proof Warm Up C: [Neven-08] (1A)

h2 Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x) (y). i, mi , xi-1 Get h associated with , m , x i-1 i-1 i-1 i-1 i H-Query If * Random xi hi = i (xi) xi-1 i = hi-1 hi If i = * Random zi hi = * (zi) xi-1 i = hi-1 hi-1
i

To simplify, simplify let H be FDH

1, 2 2 m1 , m2 H

h1 G

y3

x1 2 1 x2

Hash Table i, mi i, hi, xi

Sign-Query

Forgery

Proof Warm Up C: [Neven-08] (1B)

h2 Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x) (y). i, mi , xi-1 Get h associated with , m , x i-1 i-1 i-1 i-1 i H-Query If * Random xi Hash Table hi = i (xi) xi-1 i, mi i = hi-1 hi i, hi, xi Sign-Query If i = * Neven puts xi-1 in hash Random zi hi = * (zi) xi-1i is a function only one valid (hi-1 ,xi-1) i = hi-1 hi-1 there is only for each i-1, mi-1 one hi for each xi i need not be a and valid xi-1 Forgery permutation!
i

To simplify, simplify let H be FDH

1, 2 2 m1 , m2 H

h1 G

y3

x1 2 1 x2

Proof Warm Up C: [Neven-08] (2A)

h2 Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x) (y). i, mi , xi-1 Get h associated with , m , x i-1 i-1 i-1 i-1 i H-Query If * Random xi hi = i (xi) xi-1 i = hi-1 hi i, mi, xi-1 ,hi-1 xi, hi y 1 1 Verify xii-1 hii-1 Random xi hi = i (xi) xi-1 i = hi-1 hi 1
i

To simplify, simplify let H be FDH

1, 2 2 m1 , m2 H

h1 G

y3

x1 2 1 x2

Hash Table i, mi i, hi, xi

Sign-Query

Forgery

Proof Warm Up C: [Neven-08] (2B)

h2 Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x) (y). i, mi , xi-1 Get h associated with , m , x i-1 i-1 i-1 i-1 i H-Query If * Random xi hi = i (xi) xi-1 i = hi-1 hi Verify xi-1 hi-1 y i1 i1 Random xi hi = i (xi) xi-1 i = hi-1 hi 1
i

To simplify, simplify let H be FDH

1, 2 2 m1 , m2 H

h1 G

y3

x1 2 1 x2

Hash Table i, mi i, hi, xi

Sign-Query

i, mi, xi-1 ,hi-1 xi, hi Still need to make sure F cant set hi , i to the wrong value on Forgery an earlier H-Query

Proof Warm Up C: [Neven-08] (3)

h2 Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x) (y). i, mi , xi-1 Get h associated with , m , x i-1 i-1 i-1 i-1 i H-Query If = * Random zi hi = * (zi) xi-1 i = hi-1 hi-1
i

To simplify, simplify let H be FDH

1, 2 2 m1 , m2 H

h1 G

y3

x1 2 1 x2

Hash Table i, mi i, hi, xi

Sign-Query

Forgery

*, m*,hi, xi

Get zi, xii-1 associated with *, m* m 1 Return claw (xi, zi) because * (zi) = hi xi-1= i (xi)

Proof Warm Up D: Our version of [Neven-08] (1A)

h2 Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x) (y). Instead of the H-Table, we use an H-Tree. i ,mi ,xi-1 H-Query H Query
i

2 m2

h1 G

y2

x1 2 1 x2

1 ,m1 , 1, h1 , y1, 2 ,m2 ,x1 2, h2, 3 ,m3 ,x2 y3, z3, 3, h3

Sign-Query

2 ,m 2 ,x1 m x 2, h2, y2,

Forgery

Proof Warm Up D: Our version of [Neven-08] (1B)

h2 Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x) (y). Instead of the H-Table, we use an H-Tree. i ,mi ,xi-1 H-Query H Query
i

2 m2

h1 G

y2

x1 2 1 x2

1 ,m1 , 1, h1 , y1, 2 ,m2 ,x1 2, h2, 3 ,m3 ,x2 y3, z3, 3, h3

Sign-Query

2 ,m 2 ,x1 m x 2, h2, y2,

No longer a vector! g Forgery

Proof Warm Up D: Our version of [Neven-08] (2)

h2 Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x) (y). Instead of the H-Table, we use an H-Tree. i ,mi ,xi-1 H-Query H Query
i

2 m2

h1 G

y2

x1 2 1 x2

1 ,m1 , 1, h1 , y1, 2 ,m2 ,x1 y2, 2, h2, * ,m3 ,x2 y3, z3, 3, h3

Tether to parent with (, y) st. (xi-1) = y ( Sign-Query Retrieve hi-1 from parent If i * If i = * Random xi Random zi yi= i (xi) yi= i (zi) hi = yi xii-1 hi = * (zi) xi-1 1 1 i = hi-1 hi i = hi-1 hi-1 Forgery

Proof Warm Up D: Our version of [Neven-08] (3)

h2 Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x) (y). Instead of the H-Table, we use an H-Tree. i ,mi ,xi-1 H-Query H Query
i

2 m2

h1 G

y2

x1 2 1 x2

1 ,m1 , 1, h1 , y1, 2 ,m2 ,x1 y2, 2, h2, * ,m3 ,x2 y3, z3, 3, h3

Tether to parent with (, y) st. (xi-1) = y ( Sign-Query Claim: Probability < 2-Length(y) 1 1 that -11(y1 ) = -12(y2 ) Proof: parent is a function. yparent is random. s a do . Forgery w.h.p only 1 parent.

Finally! Proof of our scheme (1)

h2 Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x) (y). Instead of the H-Table, we use an H-Tree. i ,mi ,ri, xi-1 H-Query H Query
i

2 m2 r2

h1 G

y2

x1 2 1 x2

1 ,m1 ,r1,, 1, h1 , y1, 2 ,m2 , r2, x1 y2, 2, h2,

Randomized Hash Sign-Query H-Queries H Q i are the same, h just add r to each node Forgery

* ,m3 , r3, x2 y3, z3, 3, h3

Finally! Proof of our scheme (2)

h2 Proof: If forger F succeeds we find a claw *(x)=*(y) succeeds, (x) (y). Instead of the H-Table, we use an H-Tree. i ,mi ,ri, xi-1 H-Query H Query i Abort unlikely if 2Length(r) > qH qS Sign-Query i, mi, xi-1 ,hi-1 xi, hi No verify! Just abort if F set hi , i Forgery in an earlier H-Query 2 m2 r2 H

h1 G

y2

x1 2 1 x2

1 ,m1 ,r1,, 1, h1 , y1,

2 ,m2 , r2, x1 y2, 2, h2, Random ri xi Abort if i, mi,ri , xi-1 in H-Tree! r hi = i (xi) xi-1 i = hi-1 hi QED

Finishing Up the Design of our Scheme

2 m2 r2 H

h1 h2 G

y2

x1 2 1 x2 , b2

Make H be a hash and G be a full domain hash

So hi is 128 bits, not 2048 bits (i.e. Length(hi ) = 2log(qH ), not Length())

Compute the randomness as ri =PRF(mi,xi-1,hi-1)

Combinatorial argument reduces Length(r) from log(qH Because of G, a r-collision in the H-Query (i.e. on

qS) to 2log(qS)

i ,mi ,ri ,xi-1 ) i not always a collision on an G is t l lli i G-query! (which also t k i hi-1) ! ( hi h l takes in

Remove and carry around one bit of xi y

To deal with permutations over different domains (different RSA keys) Now signature grows by 129 bits / signer, not 128 bits / signer.

Conclusions and Open Questions

Sequential Aggregate Signatures Based on claw-free permutation in the random oracle model Lazy verification No knowledge of others public keys required to sign Fully specd and implemented in OpenSSL Sig length grows ~128 bits/ signer Can we improve on this? B t pairings are getting faster and faster But: i i tti f t df t
With pairings, shorter signatures and can be non-sequential Still far from RSA verification with short exponent e Speed requires very special curves, how secure are they?

Fin Fi

http://www.cs.bu.edu/~goldbe/papers/bgpsec-sigs.html

Princeton University