Sequential Aggregate Signatures with Lazy Verification from Trapdoor Permutations

Transcription

1 Sequential Aggregate Signatures with Lazy Verification from Trapdoor Permutations Kyle Brogle 1 Sharon Goldberg 2 Leo Reyzin 2 1 Stanford University; work done while at Boston University 2 Boston University Asiacrypt 2012 Beijing, China 6 December 2012

2 BGP Internet Routing between Autonomous Systems (ASes) Alice Bob: 18.*.*.* has path Alice MIT Alice: 18.*.*.* has path MIT BU: 18.*.*.* has path Alice MIT MIT Owns 18.*.*.* Bob BU: 18.*.*.* has path Bob Alice MIT MIT BU

3 BGPSEC Sign announcements sent Include announcements you received for the path Problem: Announcements get big! Alice: (MIT,18.*.*.*) Alice MIT Alice: (MIT,18.*.*.*) Bob: (Alice,MIT,18.*.*.*) Alice: (MIT,18.*.*.*) BU: (Alice,MIT,18.*.*.*) Bob Alice: (MIT,18.*.*.*) Bob: (Alice,MIT,18.*.*.*) BU: (Bob,Alice,MIT,18.*.*.*) BU

4 Lazy Verification Problem: To verify these signatures, routers need to retrieve and maintain ~40,000 public keys. ard to do with low latency packet forwarding. Want to be able to defer verification of signatures time permits (but can t afford to defer sending announcements) Must be able to sign before verifying. Alice Alice: (MIT,18.*.*.*) MIT Alice: (MIT,18.*.*.*) Bob: (Alice,MIT,18.*.*.*) Alice: (MIT,18.*.*.*) BU: (Alice,MIT,18.*.*.*) Bob Alice: (MIT,18.*.*.*) BU Bob: (Alice,MIT,18.*.*.*) BU: (Bob,Alice,MIT,18.*.*.*)

5 Sequential Aggregate Signatures m 1, m 2, sig 2 m 3, sig 3 Best known aggregate signature scheme is BGLS [Boneh-Gentry-Lynn-Shacham 03] Based on Pairings over Elliptic Curves as desired properties, but would be nice to have alternative from different assumptions. sig 1 [Fischlin-Lehmann-Schröder 11] Variant of BGLS with stronger security guarantees. Guarantees aren t needed in BGP, but are interesting in other contexts. What about an alternative built from TDPs? All known constructions without pairings: Don t allow for lazy verification Some operations using other signers public keys

6 Sequential Aggregate Signatures m 1, sig 1 m 2, sig 2 m 3, sig 3 Sequential Aggregate Sigs can solve the problem of large announcements One signature instead of n But can Sequential Aggregate Sigs also andle lazy verification? Two prior schemes from TDPs: By Lysyanskaya-Micali-Reyzin-Shacham (LMRS) By Neven Both require verifying the aggregate-so-far before signing (no lazy verification), and both use other signer s public keys in signing operation. Goal: Build a scheme from TDPs, removing requirement for verify before sign to allow for lazy verification. To do so, we will have to let sig grow by a small amount per signer (much less than growth in msg length)

7 Previous Sequential Aggregate Signature Schemes

8 Full-Domain ash RSA [Rivest-Shamir-Adleman 78, Bellare-Rogaway 93] Going to use RSA as an example for today, but can be done with any TDP. ash function (full RSA domain outputs; random oracle ). Public key PK = (n, e). Secret key SK = (n, d). Signer: y = (m) x = y d mod n Verifier: y = (m)? y = x e mod n m m y? = y RSA 1 RSA x x

9 LMRS Signature Scheme [LMRS 04] Signer 1: PK 1 m 1 y 1 RSA 1 x 1 Signer 2: PK 1, PK 2 m 1, m 2 2 y 2 RSA 1 x 2 Steps for Signer 2: Check that PK 1 specifies permutation Verify x 1 using PK 1, m 1 Possible to generate a malicious PK that doesn t specify a permutation. 2 = (PK 1, PK 2, m 1, m 2 ) y 2 = 2 x 1 d x 2 = y 2 2 mod n 2 Prevents Lazy Verification (Need to verify aggregateso-far before you add your sig)

10 LMRS Fails Under Lazy Verification Signer 2 wants to sign m 2 But Signer 1 wants to get a sig on bad-m 2 (Chosen Message Attack) Signer 1: PK m 1 1 PK 1, PK 2 m 1, m 2 2 RSA 1 x 1 PK 1, PK 2 m 1, bad-m 2 Signer 2: PK 1, PK 2 m 1, m 2 bad- 2 2 bad-x y 1 2 RSA 1 x 2 Valid aggregate sig on (m 1, bad-m 2 )

11 Neven Signature Scheme [Neven 08] ash functions (short outputs), G (full RSA domain outputs) Signature has two components: (x, h) Signer 2: h PK 1,PK 1 2 m 2 1, m 2 G Signer 3: h 2 y 2 RSA 1 x 1 x 2 PK 1, PK 2, PK 3 m 1, m 2, m 3 y 3 3 G RSA 1 x 3 Verify (x 1, h 1 ) using PK 1, m 1 2 = (PK 1, PK 2, x 1, m 1, m 2 ) h 2 = 2 h 1 y 2 = G(h 2 ) x 1 d x 2 = y 2 2 mod n 2 h 3 No more certified permutations Without verification, same bad-m 2 attack works! Will always work if signer i knows exactly what goes into RSA -1 for signer i+1 Need something to be out of previous signer s control!

12 Our Scheme [BGR 12] ash functions (short outputs), G (full RSA domain outputs) Signature has two components: (x, h) plus an r value per signer Signer 2: x h 1 PK 1 1,PK 2 2 y m 2 1, m 2 G RSA 1 x 2 Signer 3: r 2 h 2 PK 1, PK 2, PK 3 3 y m 3 1, m 2, m 3 G RSA 1 x 3 Random r 2 Verify (x 1, h 1 ) using PK 1, m 1 2 = (PK 1, PK 2, x 1, m 1, m 2 ), r 2 ) h 2 = 2 h 1 y 2 = G(h 2 ) x 1 d x 2 = y 2 2 mod n 2 r 3 h 3 No more verification necessary malicious signer i cannot predict input to RSA -1 for signer i+1 Lazy Verification Achieved! Note: Security proof improves if r is pseudorandom; see paper for interesting combinatorial tricks.

13 Need for Lazy Verification Sequential Aggregate Signatures Our Scheme Proof Benchmarks

14 Security Proof Warm Up: Full-Domain-ash Proof [Bellare-Rogaway 93] m y RSA 1 x y (m)? y F x = RSA 1 (y) Proof logic: if forger F succeeds, we can invert RSA on a given y is a random oracle F has to query it answer one query with y By programming the random oracle to respond with y, we can ensure that if the forger succeeds, we will have inverted RSA on a given y.

15 Security Proof cont d PK 1 m 1 r 1 1 h 1 G x 1 y 1 RSA 1 x 1 Note G(h Reduction 1 ) = RSA PK1 sees (x 1 ). This can Reduction all be queries used to to pair. the two. needs Need to find one x 1 to match to x 1. PK 2 m 2 r 2 2 h 2 G?? y 2 RSA 1 x 2 Now we have a pair of matched queries, so we ve found x 1! G G(h 2 )? (x 1, )? ( )? y 2 x 2 = RSA 1 (y 2 ) F

16 Need for Lazy Verification Sequential Aggregate Signatures Our Scheme Proof Benchmarks

17 Benchmarks Implemented our scheme with OpenSSL primitives Benchmarks computed with software implementations. Things may look different in hardware. Benchmarks computed using OpenSSL: 2GB Ram, 2.4Gz Core i3 BLGS benchmark computed with MIRACL crypto library, as OpenSSL did not have an implementation. Benchmarks considered were signature length, verify time, and sign time.

18 Signature Length Bit Length ECDSA shorter for small k Average path length Path length k BGLS-256 RSA-2048 BGR-2048 ECDSA-256 Weaker routers see longer k => BGR more efficient

19 Verify Time Time (ms) BGLS costs approx 20ms + 6ms per signer Average path length BGLS-256 RSA-2048 BGR-2048 ECDSA Path length k

20 Sign Time Time (ms) RSA-2048 BGR-2048 ECDSA-256 BGLS Out Degree

21 Conclusions Sequential Aggregate Signatures From any TDP (in RO model) Lazy Verification (In fact, don t need to know previous signers at all) Signature grows ~128 bits/signer Already have linear growth due to messages, which are on average longer than 128 bytes. ± Speed comparable to RSA (fast verify, slower sign).