1 / 27

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 2 R ” mean? . Motivation.

galena
Download Presentation

Pairings in “Real Life”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. Questions? Thank You! USP/DCU

More Related