This section reviews the main cryptographic primitives used in the pro- tocol reBGP, namely Identity-based Aggregate Signatures.
3.2.1
Identity-based Aggregate Signature
Traditional public key cryptography relies on one or more trusted au- thorities that issue certificates to bind users to public keys. Hence, before encrypting a message under one’s public key, its authenticity must be ver-
ified by means of a valid certificate issued by the authority. Similarly, a certificate is required to validate the (public) verification key of a party, before verifying its signatures.
Certificate distribution and management requires a complex infras- tructure known as Public Key Infrastructure (PKI). While traditional cryp- tography has been previously recommended to secure Internet-domain routing [73], the proposal has never been adopted because of the involve- ment of the PKI and complex trust relations among its components.
Identity Base (IB) Cryptography is an effective alternative to traditional Public Key cryptography that relies on certificates to endorse public key authenticity. In an IB cryptographic scheme, the identities of the parties “are” their public keys. In other words, any string can serve as a pub- lic key; corresponding private keys are managed and issued by a trusted authority, referred to as Private Key Generator (PKG). The latter is only active when issuing new keys.
The main advantages of the IBE Cryptosystems, are related to the its use of user identity’s attributes (e.g email addresses or identity numbers) instead of digital certificates, for cryptographic operations. This environ- ment significantly reduces the complexity of a cryptography system by eliminating the need for generating and managing users’ certificates, so reducing communication and computational costs. Although an IBE cryp- tosystems avoids the need a PKI, it relies on a trusted third party, namely the Private Key Generator (PKG) which generates and issues the pub- lic/private keypairs. Furthermore, using such settings, there is no need to managing a public key infrastructure, including the CRLs (Certificate Revocation Lists).
It is relevant of mention other advantages of an IBC. In a IBC all the encryption keys are always available for all recipients. In fact, the encryp- tion key is derived mathematically from the receiver’s identity. This con- dition also assures the server can securely regenerate keys for recipients as needed.
Identity Based Aggregate Signatures (IBAS) allow multiple users to sign multiple messages and aggregate all signatures in a fixed-size token.
Given the identity of the signing parties, the signed messages and the ag- gregated signature, anyone can verify the validity of the signatures over their respective messages.
More formally, an IBAS scheme can be defined as a tuple of the form: Setup, ExKey, Sign, Agg, Veri f y
where:
• pkPKG, skPKG ←Setup(λ)on input security parameter λ, outputs the
PKG public/private key pair pkPKG, skPKG.
• pki, ski ← ExKey(skPKG, i) on input the PKG private key sk and a
string i, outputs public/private key pair pki, ski.
• σ ← Sign(ski, m) on input secret key skiand message m produces a
signature on m under key ski.
• σ ← Agg(σ1, . . . , σn) on input signatures σ1, . . . , σn produces an ag-
gregated signature σ.
• {0, 1} ← Veri f y(pkPKG, σ, m1, ...mn, i1, . . . , in) takes as input public
key pkPKG, a number of messages m1, . . . , mn with their respective
signers i1, . . . , in and the aggregate of their signatures σ; it outputs 1
if σ← Agg(σ1, . . . , σn)and, for 1≤i≤n, σi ←Sign(ski, mi).
Protocol reBGP uses the IBAS scheme proposed in [57] that allows mul- tiple signers to sign multiple messages in such a way that the total verifi- cation information, apart from a description of who signed what, consists only of a short aggregate signature. In the following, the algorithms in [57] has briefly reviewed:
Setup(λ)is run by the PKG to define its secret key and public parameters:
1. Define groups G, GT of prime order q and bilinear map e : G×G →
GT
3. Randomly pick s ∈ Zqand set Q=sP
4. Define Hash functions H1, H2: {0, 1}∗ → G and H3 :{0, 1}∗ → Zq
5. Set skPKG =s and pkPKG =G, GT, e, P, Q, H1, H2, H3
ExKey(skPKG, IDi)is run by the PKG to compute the secret key of singer with identity IDi:
1. Set ski = {sPi,0, sPi,1}where Pi,j =H1(IDi, j) ∈ G
Sign(ski, mi) is run by signer with identity IDi to sign an arbitrary mes-
sage mi:
1. Pick random string w 2. Compute Pw= H2(w) ∈G
3. Compute ci = H3(mi, IDi, w)
4. Pick random ri ∈ Zq
5. Compute σi = (w, Si0, Ti0)where
S0i =riPw+sPi,0+cisPi,1and Ti0 =riP.
Aggregate(σ1, . . . , σn) allows to aggregate an arbitrary number of signa- ture that use the same w. The procedure can be run by any party as it requires no secrets.
1. Parse σi as(w, S0i, Ti0)
2. Compute σ1,...,n = (w,∑ni=1S0i,∑ n i=1Ti0)
Verify(pkPKG, σ1,...,n, m1, . . . , mn, ID1, . . . , IDn) is run to verify an aggre- gate signature σ1,...,n where each singer IDi has signed message mi (1 ≤
i≤n).
1. Parse σ1,...,n as(w, Sn, Tn)
2. Check that
The scheme is provably secure in the random oracle model, assuming the hardness of computational Diffie-Hellman over groups with bilinear maps.