Pairings in “Real Life”

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

Motivation • Solid theoretical basis from this workshop. • Applications taken from “real life”. • Question: what does “life 2R” mean?  USP/DCU

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? USP/DCU

Case study #1 • 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. USP/DCU

Requirements • 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. USP/DCU

Assessment • 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? USP/DCU

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. USP/DCU

Digression: BLS signatures • 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. USP/DCU

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). USP/DCU

Solution and results • 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. USP/DCU

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. USP/DCU

Features of the scenario • 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. USP/DCU

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. USP/DCU

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! USP/DCU

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. USP/DCU

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”). USP/DCU

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 + tfori 1 to (m+1)/2 {uxP, xPpxP, yPpyPgu¢(xP + xQ) + yP + yQ + xP + (u + xQ)s + t ff¢g xQxQ2, yQyQ2}returnf (22m–1)(2m–2(m+1)/2+1) USP/DCU

Solution and results • 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. USP/DCU

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. USP/DCU

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. USP/DCU

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. USP/DCU

Solution and results • 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) USP/DCU

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. USP/DCU

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{k2N : n | k(p)} = 12 USP/DCU

Advertisement: BN curves • … 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. USP/DCU

Advertisement: BN curves • … 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  USP/DCU

Questions? Thank You! USP/DCU

Pairings in “Real Life”