Paulo S. L. M. Barreto (SFI Walton Fellow) Pairings in “Real Life”

Paulo S. L. M. Barreto(SFI Walton Fellow)

Pairings in “Real Life”

USP/DCU© Paulo S. L. M. Barreto 2009 2

Solid theoretical basis from this workshop.

Applications taken from “real life”.

Question: what does “life 2 R” mean?

Motivation


Our goal: sample government, financial and general business necessities that can be addressed with pairings.

When and how to use pairings in practice: case studies.

Where do we go next?

Motivation


Tax payment authentication. Government of São Paulo, Brazil. > 40£106 inhabitants, 1/3 of GDP.

Previous system (< 2001): Mechanical, non-cryptographic authentication system

(authenticating printer). Manual verification, requiring a trusted user.

Frauds! Government admitted to 5% of tax payment evasion

out of a $500£106 gross monthly tax revenue.

Case study #1


Automatic process, without manual intervention. Open specification, unencumbered by patents. Public-key scheme with security level roughly

equivalent to RSA-1024. Authentication tag must be printable on two

alphanumerical lines (320 bits). Half of the available space is occupied by context

information (user id, bank id, amount paid, date, etc).

Volume of ~2–4£106 authentications a month must be handled on a single Pentium II 450 MHz PC.

Requirements


160-bit signatures: (EC)DSA won’t do.

Available options at the time: CFS OP/BLS (preprint) HFE schemes

Would any of these be acceptable?

Assessment


Assessment

CFS Very slow to generate (max workload ~40£103

sigs/month on target platform) Covered by patents.

HFE schemes Efficiency/security unknown. Covered by patents.

BLS Reported efficiency scaled to ~400£103 sigs/month on

target platform. No patents.


Setup: e: G1 £ G2 GT, H: {0,1}* G1.

Key pair: (s random, V sQ G2).

Signature: sH(m) G1. Verification: accept (m, ) e(, Q) =

e(H(m), V). Explanation:

e(, Q) = e(sH(m), Q) = e(H(m), Q)s. e(H(m), V) = e(H(m), sQ) = e(H(m), Q)s.

Digression: BLS signatures


Solution and results

BLS was the only plausible choice. Performance still fell short of the reqs by one

order of magnitude.

BKLS/GHS variant of Miller’s algorithm, use of an MNT6 curve and several other optimizations increased performance by a factor of 55 (even more afterwards).



All reqs satisfied: CPU >80% idle in initial version, now >99%. There was even room for business rule

improvements. Government reported that frauds fell to

0% (sic), increasing tax revenue from $500£106 to $1.5£109 (sic).

Still in use today – no further modification needed.


Case study #2

Wireless sensor networks (WSN). Large number of applications:

Weather monitoring. Remote medical monitoring. Inventory control. Battlefield management.

Key agreement protocol needed for node-to-node secure communication.


Severely constrained platform: Low processing power. Restricted bandwidth. Small storage space. Battery.

Typically only 4 KiB RAM. Transmitting a bit is ~104 times more

battery-consuming that processing that same bit on a WSN.

Features of the scenario


Assessment

A typical authenticated key agreement protocol (e.g. HMQV-p) involves 2–3 passes of message exchanges between the involved parties. Very bad for WSN.

Computing a pairing is a very processor-intensive operation: Roughly one order of magnitude more than elliptic

curve arithmetic. May be a minor concern in WSNs.


Assessment

Identity-based techniques improve the scenario.

Sakai-Ohgishi-Kasahara authenticated key agreement protocol (SOK): Each user required to compute one pairing

for each other user she wants to establish a session key with.

No message exchange at all between users!


Digression: SOK protocol

Setup: e: G £ G GT, H: {0,1}* G. Symmetric pairing: e(A, B) = e(B, A).

KGC key pair: (s random, V sP G). ID-based private key: PA sH(IDA) G. Authenticated shared key:

KAB = e(PA, H(IDB)) = e(PB, H(IDA)) GT.

Pros & Cons: purely offline protocol comes at the price of having a fixed shared key.


Assessment

Caveat: some choices may be better than others.

How about generic pairing parameters, e.g. BN curves?

Obstacles to this approach: Code/memory reqs may not fit available space. Slow processing may be annoying even if acceptable. Overkill anyway (“killing a flea with an atomic

bomb”).


Digression: the T pairing

Fq2 = F [s]/(s2 + s + 1), Fq4 = Fq2[t]/(t2 + t + s).Input: P = (xP, yP), Q = (xQ, yQ)Output: T(P, Q)u xP + 1f u¢(u + xQ) + yP + yQ + b + 1 + (u + xQ)s + tfor i 1 to (m+1)/2 { u xP, xP pxP, yP pyP

g u¢(xP + xQ) + yP + yQ + xP + (u + xQ)s + t f f¢g xQ xQ

2, yQ yQ2

}return f (22m–1)(2m–2(m+1)/2+1)



The T pairing on binary supersingular curves is the most efficient choice for a WSN. Contrary to what may be expected from a

general-purpose processor. Aranha et al, CHiLE’2009.

Supersingular varieties limit achievable security level: so what? Typical security reqs on a WSN not too high:

ephemeral data points to be consolidated.


Case study #3

Secure SMS messaging: Business information exchange. Micropayments.

Heterogeneous, ad-hoc scenario: Servers for administrative tasks. “High”-power mobile phone processors. “Low”-power mobile phone processors.

Choice of parameters depends not only on the technical bottlenecks but on average “customer satisfaction” as well.


Requirements

Raw space: 140 bytes per message. One SMS exchange per pair of users is

acceptable for “certificate exchange”. 85% of raw space must be available for a

purely encrypted message, and 70% for an encrypted and signed message.

Any mobile phone with an API should be allowed.

Must not be (purely) identity-based.


Assessment

Usual certificates take 2-4 KiB (15–30 SMS messages per user pair just to exchange certificates).

Conventional crypto overhead of several SMS messages per user message.

For a strict space of 140 bytes, constraints imply max overhead of ~20 bytes for pure encryption and ~40 bytes for encryption and signature.



Self-certified pairing-based procotol tightly addresses reqs. Pairing computation time may be as high as

8–10 s (required only once per user pair). Nearly all mobile phones with a JVM are OK.

Other solutions? Certificateless protocol would do as well. New protocols with interesting properties,

e.g. Fiore and Gennaro, ePrint 2009/174 (IBDH, no pairings except in security proofs)


Overall analysis

All case studies involve more or less constrained platforms where pairings should naively be too inefficient to use.

Yet the intended high-level, real-world application was only feasible because of pairings!

Moral: do not be afraid of using pairings – they look complicated and expensive, but are very useful and effective.


Advertisement: BN curves

E(Fp): y2 = x3 + b #E = n = p + 1 – t p(u) = 36u4 + 36u3 + 24u2 + 6u + 1 n(u) = 36u4 + 36u3 + 18u2 + 6u + 1 t(u) = 6u2 + 1 t2 – 4p = –3(6u2 + 4u + 1)2

j(E) = 0 min{k 2 N : n | k(p)} = 12



… facilitate pairings at the 128-bit security level.

… are good for all pairing applications, including short signatures.

… support a sextic twist, so the Q and P parameters of the *ate pairing are defined over Fp2 and Fp respectively.

… allow for fast arithmetic in all groups involved.


… support pairing compression. … are friendly to optimal pairings (1/4

length loop). … are plentiful and easily found. … I could go on… … thanks to Mike Scott from whom I stole

the advertisement slides



Questions?

Thank You!

Paulo S. L. M. Barreto (SFI Walton Fellow) Pairings in “Real Life”

Documents

uspdcu paulo

assessment slide

motivation slide

real life slide

v sq g

tax payment authentication

case study

bls signatures