Agg Sigs Slides IBM

8/6/2019 Agg Sigs Slides IBM

1/48

Sequential Aggregate Signatures

Kyle Brogle Sharon Goldberg Leo ReyzinBoston University

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

Princeton University

IBM Research, New YorkApril 4, 2011


2/48

This Talk

-


3/48

How Secure is Internet Routing Today? (1)

I am Verizon

Verizon

. . .

The InternetChina Telecom

London InternetExchan e

UK ISP


4/48

How Secure is Internet Routing Today? (2)

I am VerizonThis packet is

Verizon

. . ..

The InternetChina telecom

London InternetExchan e

I am Verizon

UK ISP69.82.0.0/15

(and 50k other networks)


5/48

BGP: The Internet Routing Protocol (1)

a s rom u onomous ys ems es o pre xesare set up via the Border Gateway Protocol (BGP).

BU

IBM, Prefix

IBM

Local

Comcast

Comcast, IBM, Prefix,


6/48

BGP: The Internet Routing Protocol (2)

AT&T IBM Prefix

a s rom u onomous ys ems es o pre xesare set up via the Border Gateway Protocol (BGP).

BU

IBM

Local BU Ranking:

Comcast,

AT&T, IBMLocal, Comcast, IBM

Local, Comcast, IBM, Prefix


7/48

Attacks on BGP: Announcing false paths

AT&T IBM Prefix

urren y as no mec an sm o va a ecorrectness of paths in BGP announcements.

BU

IBM

Local BU RankingLocal

Comcast,

AT&T, IBMLocal, Comcast, IBM

Local, IBM, Prefix

ep o e en ng aga ns ac s:

The RPKI that certifies mapping of IP Prefixes and PKs to AsesOperators are actually deploying this now!


8/48

Defending Against Attacks with BGPsec

- .

New design of this went to the IETF in Prague just last week.

BU

,

Local: (Comcast, IBM, Prefix)

BU: Local, Comcast, IBM, Prefix

IBM

Local

Comcast

Comcast: (IBM, Prefix) ,



9/48

Technical Hurdles for BGPsec

es(Many PKs)

300K IP prefixes

( Store manyBGPsec msgs)

Routers are

resourceconstrained

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


10/48

Digital Signatures for BGPsec: Desiderata

Routers must maintain local cache

>

requires no knowledge

Challenge:

Lazy VerificationLazy Verification

outers must process sec

announcements quickly, even

load permits or

.

Challenge: Aggregate signaturesAggregate signatures

Routers must store BGPsecannouncements for each prefix.

shorten length ofsignature chains

[BGR][BGR] RSA sequential aggregate signature w. lazy verification.

(or, a randomized version of [Neven08])


11/48

msms

[BGR11] Instantiation with RSA, SHA-1, and HMAC

b1 ,b2 ,,bn

-

b1 ,b2 ,,bn-1 nth signer

2048 bits256 bits

hn xn

-

hn-1 xn-1

, n

128 bits

1. rn = HMACk(msgn | xn-1 | hn-1) 128 bitsgn . n n-1 n n n n-1 ts

3. xn = RSA ( G(hn) + xn-1) 2048 bitsTo

Si

Signer has a local (unshared) key k used to compute HMAC

4. Remove 1st bit of xn and save it as bn 1 bits

In our implementation: k=256 bits, and 2048 bit RSA

H = SHA-256; HMAC uses SHA-256; G is MGF with SHA-256


12/48

For our target application of BGPsec

Comcast: (IBM, Prefix)


LocalISP

, , ,

The real competition is nothing fancy: Trivial RSA Trivial ECDSA

Both of which allow:1) Lazy verification,


13/48

Benchmarks and Performance Comparison

- - - -PKCS, SHA-256

exp 65537

SHA-256 and RSA

exp 65537

Total Si

Length

n s + + n n s

Average Sig

n = 3.5

Signing Time 11.8 ms 11.9 ms 2.33 ms

VerificationTime

n * 0.27 ms n * 0.30 ms n*2.77 ms

Benchmarks computed using OpenSSL & (our implementation)

on a laptop: 2GB Ram, Core i3 at 2.4GHz running Linux Ubuntu


14/48

Signature Lengths

5

Average path length in BGP

h

10000BitLengt

BGR

2048

5000

ECDSA256ea er rou ers see onger

n => BGR more efficient

0

n, path length

1 2 3 4 5 6 7 8 9 10

ECDSA shorterfor small n


15/48

Verify Time

25

30

Average path length in BGP

20s)

15

im

e(

BGR

2048

5

10 ECDSA256Verify time of BGR looksjust like basic RSA

0

1 2 3 4 5 6 7 8 9 10

n, path length


16/48

This Talk

-

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


17/48

Aggregate Signatures

Aggregate signature: [Boneh-Gentry-Lynn-Shacham 2003]

Signer 3Signer 2Signer 1

m3, sig3m2, sig2m

1, sig

1

Aggregate

statements at once


18/48

The Aggregate Signature Tradeoff

ase on a r ngs over pt c urves less standard assumptions

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

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


19/48

Full-Domain Hash RSA

- - -Hash functionH(full RSA domain outputs; random oracle).

Public ke K= (n, e). Secret ke SK= (n, d).

Steps of the Signer:

1y x

y = (m)

= d mod n

2048bit 2048bit

Steps of the Verifier:

y =H(m)?

RSAy

xm Hy =x e mod n =


20/48

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

Steps of Signer 2:

Verifyx1 usingPK1, m1

SA1y1PK1Si ner 1:

2048bit 2048bit

1y2 xPK1,PK2

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

2y2 = 2 x1m1, m2

x2 =y2 mod n2d2

1y33

m1, m2, m3, ,

Check thatPK1,PK2 specify permutations

Steps of Signer 3:

Verifyx2 usingPK1,PK2, m1, m2


21/48

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

Check thatPK1,PK2,PK3 specify permutations

SAy1PK1

?=

y2 xPK1,PK2

m1

2

m1, m2

y33

m1, m2, m3, ,


22/48

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

Steps of Signer 2:

Verifyx1 usingPK1, m1

Either proofs, orlong verification

2 = (PK1,PK2, m1, m2)

y2 = 2 x1 Prevents lazy x2 =y2 mod n2

d2ver cat on

Re uires other

Check thatPK1,PK2 specify permutations

Steps of Signer 3:

signers PKs

Verifyx2 usingPK1,PK2, m1, m2


23/48

[LMRS] Fails under Lazy Verification.

Adversary knows Signer 2 wants to sign m2.

But adversary wants to get a sig on bad-m2.

xSA1y1PK1

Adversary:

m1

PK1,PK2 2m1, m2

PK1,PK2bad-2

SA1y2 xPK1,PK2

m1,bad-m2 bad-x1

Si ner 2:2

m1, m2

Valid aggregate sig on (m1, bad-m2)


24/48

[Neven08]: Sign

Hash functionH(short outputs), G (full RSA domain outputs)

Steps of Signer 2:

x1 2 =H(PK1,PK2,x1, m1, m2) Verify (x1, h1) usingPK1, m1

1

SA1y2 xm1, m2 2

PK1,PK2

G

h2=2 h1

y2 = G(h2)x1

h2

x2 =y2 mod n22 2048bit 2048bit256bit

RSA1 3m1, m2, m3

3 1,

2

,3 H G

h3x3

Steps of Signer 3:

Verify (x2, h2) usingPK1,PK2, m1, m2


25/48

[Neven08]: Verify

RSAm1

K1

H =?

=

11

SAy2m1, m2 2

PK1,PK2

x2h2

G

RSA 3m1, m2, m3

3 1,

2

,3 H x3

h G


26/48

[Neven08]: Issues

Hash functionH(short outputs), G (full RSA domain outputs) .

Steps of Signer 2:

No certified TDP,but still prevents

2 =H(PK1,PK2,x1, m1, m2) Verify (x1, h1) usingPK1, m1

2 =H(PK2,x1, m2) Requires otherOnly an artifact h2=2 h1

y2 = G(h2)x1

signers PKsof Nevens proof.We get rid of this!

x2 =y2 mod n22 Can break lazy verification in asimilar way: injecth bad-h1

x1

PK1,PK2

PK1

RSA1y2 x2

m1, m2 2

h2

H G


27/48

Our Signature Scheme

Ste s of Si ner 2: Hash functionH(short outputs), G (full RSA domain outputs)

h1x1

2 =H(PK2, r2,x1, m2) Randomr2

RSA1y2 x2m2

r2

2

h2

PK2H G

h2=2 h1

y2 = G(h2)x1 2048bit 2048bit256bit

RSA1y3m3

3

PK3H G

r3 h3

x3

x2 =y2 mod n22

Signing depends only

27 Signature grows (~128 bits / signer if r psuedorandom.)


28/48

Comparison of (Some) Aggregate Signatures

- - - -Assumption Pairings RSA RSA RSA

Non-Sequential? Yes No No No

Uncertified TDP? N/A No Yes Yes

Lazy Verify? Yes No No Yes

Signature Length(bits)

128 20482048+ 256

2048+ 256

+ 128n

except for assumption Wins on all countsexcept for sig lengthapp of BGPsec


29/48

This Talk

-

Randomized Full Domain Hash [LMRS-04] even- mprove even- ur c eme


30/48

Proof Warm Up A: Randomized Full Domain Hash

=

1 xm,r H- .H is FDH Random Oracle.

,

H-Querym,r, Randomy

=Hash Table

-

Random r, xmr x

,

, y

Abort ifalready set Set = (x)

Unlikely if2Length(r) > qHqS

Forgery

m*, r*, x* Find H-queryH(m*, r*) = (y*)

Return claw (x*,y*)


31/48

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

* = *

1y2 x2m1, m2

1, 2 H2

,

i, mi Getxi-1 associated with i-1, mi-1 *

iH-Query i Randomxi

i = i (xi)

xi-1 m

Hash Table

i = Randomzi i = * (zi) xi-1

1, xi,

Sign-Query

Forgery


32/48

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

* = *

1y2 x2m1, m2

1, 2 H2

,

H-Queryi, mii

Getxi-1 associated with i-1, mi-1 *

m

Hash Table

i Randomxi

i = i (xi)

xi-1

Verifyxi-1 Verif are ermutations

Sign-Queryxi

1, xi,

i, mi, xi-1

Randomxi i = i (xi) xi-1

Forgery


33/48

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

* = *

1y2 x2m1, m2

1, 2 H2

,

H-Queryi, mii

Getxi-1 associated with i-1, mi-1 *

m

Hash Table

i Randomxi

i = i (xi)

xi-1

There is only one

xi-1 for each i-1, mi-1

Verifyxi-1 Verif are ermutations

Sign-Queryxi

1, xi,

i, mi, xi-1

Randomxi i = i (xi) xi-1So that F cant set i

Forgery

an earlier H-Query


34/48

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

* = *

1y2 x2m1, m2

1, 2 H2

,

H-Queryi, mii

Getxi-1 associated with i-1, mi-1 = *

m

Hash Table

i Randomzi

i = * (zi)

xi-1

Sign-Query 1, xi,

, - , Return claw (xi, zi) because

* (zi) = i xi-1= i (xi)Forgery

*, m*i, xi


35/48

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

h x1

21

y3 x2m1, m2 2

h2H G

1, 2,let H be FDH

* = * , .

H-Queryi, mi, xi-1

i Get hi-1 associated with i-1, mi-1, xi-1 *i

Randomxi

hi = i (xi)

xi-1 m

Hash Table

Sign-Query i = i-1 i

Ifi = * Randomzi

i, hi, xi

hi = * (zi) xi-1 i = hi-1 hi-1

Forgery

C


36/48

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

h x1

21

y3 x2m1, m2 2

h2H G

1, 2,let H be FDH

* = * , .

H-Queryi, mi, xi-1


Randomxi

hi = i (xi)

xi-1 m

Hash Table


Ifi = * Randomzi

i, hi, xi

Neven putsxi-1 in hash

hi = * (zi) xi-1 i = hi-1 hi-1

only one valid (hi-1,xi-1)for each i-1, mi-1

i is a function there is only

Forgery

i need not be a

permutation!

i iand validxi-1

P f W U C [N 08] (2A)


37/48

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

h x1

21

y3 x2m1, m2 2

h2H G

1, 2,let H be FDH

* = * , .

H-Queryi, mi, xi-1


Randomxi

hi = i (xi)

xi-1 m

Hash Table


i, hi, xi

Verifyx - h -i, mi, xi-1,hi-1

Randomxi hi = i (xi) xi-1 =

i, i

Forgery

i i-1 i

P f W U C [N 08] (2B)


38/48

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

h x1

21

y3 x2m1, m2 2

h2H G

1, 2,let H be FDH

* = * , .

H-Queryi, mi, xi-1


Randomxi

hi = i (xi)

xi-1 m

Hash Table


i, hi, xi

Verifyx - h -i, mi, xi-1,hi-1

Randomxi hi = i (xi) xi-1 =

i, i

Still need to makesure F cant set h

Forgery

i i-1 i,

to the wrong value on

an earlier H-Query

P f W U C [N 08] (3)


39/48

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

h x1

21

y3 x2m1, m2 2

h2H G

1, 2,let H be FDH

* = * , .

H-Queryi, mi, xi-1

i Get hi-1 associated with i-1, mi-1, xi-1 = *i

Randomzi

hi = * (zi)

xi-1 m

Hash Table

Sign-Query i = i-1 i-1

i, hi, xi

* *

Forgery

, - ,

Return claw (xi, zi) because

* (zi ) = hi xi-1= i (xi)

*, m*,hi, xi

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


40/48

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

h x1

21

y2 x2m2 2

h2H G

2

* = * , .

Instead of the H-Table, we use an H-Tree.i,mi,xi-1 1,m1,

- i 1, h1, y1,

2, 2, 12, h2, y2,Sign-Query

2,m2,x12, h2,

3,m3,x2

Forgery3, 3y3, z3,

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


41/48

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

h x1

21 y

2 x2m2 2

h2H G

2

* = * , .

Instead of the H-Table, we use an H-Tree.i,mi,xi-1 1,m1,

- i 1, h1, y1,

2, 2, 12, h2, y2,Sign-Query

2,m2,x12, h2,

3,m3,x2No lon er a vector!

Forgery3, 3y3, z3,

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


42/48

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

h x1

* = *

21 y

2 x2m2 2

h2H G

2

i,mi,xi-1

, .

1,m1,Instead of the H-Table, we use an H-Tree.

Tether to parent with (, y) st.

- i 1, h1, y1,

xi-1 = y

Retrieve hi-1 from parent Ifi *

Sign-Query

2,m2,x12, h2,y2,

If = *

Randomxi yi= i (xi)

=* ,m3,x2

Randomzi yi= i (zi) = *-

i = hi-1 hiForgery3, 3y3, z3,i i i-1

i = hi-1 hi-1

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


43/48

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

h x1

21 y

2 x2m2 2

h2H G

2

* = *

i,mi,xi-1 1,m1,Instead of the H-Table, we use an H-Tree.

, .

Tether to parent with (, y) st.

- i 1, h1, y1,

xi-1 = y

Sign-Query

2,m2,x12, h2,y2,Claim: Probability < 2-Length(y)

- -

* ,m3,x2

1 1 2 2

Proof: parentis a function.is random.

Forgery3, 3y3, z3,

w.h.p only 1 parent.

Finally! Proof of our scheme (1)


44/48


h x1

2

* = *

21 y

2 x2m2 2

h2H Gr2

i,mi,ri,xi-1 1,m1,r1 Instead of the H-Table, we use an H-Tree.

, .

- i 1, h1, y1,

Randomized

Sign-Query

2,m2, r2,x12, h2,y2,

* ,m3, r3,x2

- uer es are t e same,just add rto each node

Forgery3, 3y3, z3,



45/48


h x1

2

* = *

21 y

2 x2m2 2

h2H Gr2

i,mi,ri,xi-1 1,m1,r1 Instead of the H-Table, we use an H-Tree.

, .

- i 1, h1, y1,Abort unlikely if

2Length(r)

> q qS

Sign-Query

2,m2, r2,x12, h2,y2, Random rixi

xi, hi

i, mi, xi-1,hi-1

i, i, i , i-1 -

hi = i (xi) xi-1 i = hi-1 hi

Forgery

Just abort if F set hi , i

in an earlier H-Query QED

Finishing Up the Design of our Scheme


46/48

Finishing Up the Design of our Scheme

1

21

y2 x2m2 2

h2H G

r2x2, 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), notLength())

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

om na or a argumen re uces rom H S o S

Because of G, a r-collision in the H-Query (i.e. on i,mi,ri,xi-1 )

s no a ways a co s on on an -query w c a so a es ni-1

Remove and carr around one bit ofx

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


47/48

Conclusions and Open Questions

Based on claw-free permutation in the random oracle model

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? u : pa r ngs are ge ng as er an as er

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?


48/48

n

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

Princeton University

Date post:	07-Apr-2018
Category:	Documents
Upload:	johnny-daisy-wang
View:	229 times
Download:	0 times

Agg Sigs Slides IBM

Documents