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

2. 2 USP/DCU © Paulo S. L. M. Barreto 2009  Solid theoretical basis from this workshop.  Applications taken from “real life”.  Question: what does “life 2 R ” mean? Motivation

3. 3 USP/DCU © Paulo S. L. M. Barreto 2009  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

4. 4 USP/DCU © Paulo S. L. M. Barreto 2009  Tax payment authentication. Government of São Paulo, Brazil. > 40 £ 10 6 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 £ 10 6 gross monthly tax revenue. Case study #1

5. 5 USP/DCU © Paulo S. L. M. Barreto 2009  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 £ 10 6 authentications a month must be handled on a single Pentium II 450 MHz PC. Requirements

6. 6 USP/DCU © Paulo S. L. M. Barreto 2009  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

7. 7 USP/DCU © Paulo S. L. M. Barreto 2009 Assessment  CFS Very slow to generate (max workload ~40 £ 10 3 sigs/month on target platform) Covered by patents.  HFE schemes Efficiency/security unknown. Covered by patents.  BLS Reported efficiency scaled to ~400 £ 10 3 sigs/month on target platform. No patents.

8. 8 USP/DCU © Paulo S. L. M. Barreto 2009  Setup: e: G 1 £ G 2  G T, H : {0,1}*  G 1.  Key pair: (s  random, V  sQ  G 2 ).  Signature:   s H (m)  G 1.  Verification: accept (m, )  e(, Q) = e( H (m), V).  Explanation: e(, Q)= e(s H (m), Q)= e( H (m), Q) s. e( H (m), V)= e( H (m), sQ)= e( H (m), Q) s. Digression: BLS signatures

9. 9 USP/DCU © Paulo S. L. M. Barreto 2009 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).

10. 10 USP/DCU © Paulo S. L. M. Barreto 2009 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 £ 10 6 to $1.5 £ 10 9 (sic).  Still in use today – no further modification needed.

11. 11 USP/DCU © Paulo S. L. M. Barreto 2009 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.

12. 12 USP/DCU © Paulo S. L. M. Barreto 2009  Severely constrained platform: Low processing power. Restricted bandwidth. Small storage space. Battery.  Typically only 4 KiB RAM.  Transmitting a bit is ~10 4 times more battery-consuming that processing that same bit on a WSN. Features of the scenario

13. 13 USP/DCU © Paulo S. L. M. Barreto 2009 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.

14. 14 USP/DCU © Paulo S. L. M. Barreto 2009 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!

15. 15 USP/DCU © Paulo S. L. M. Barreto 2009 Digression: SOK protocol  Setup: e: G £ G  G T, H : {0,1}*  G. Symmetric pairing: e(A, B) = e(B, A).  KGC key pair: (s  random, V  sP  G ).  ID-based private key: P A  s H (ID A )  G.  Authenticated shared key: K AB = e(P A, H (ID B )) = e(P B, H (ID A ))  G T.  Pros & Cons: purely offline protocol comes at the price of having a fixed shared key.

16. 16 USP/DCU © Paulo S. L. M. Barreto 2009 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”).

17. 17 USP/DCU © Paulo S. L. M. Barreto 2009 Digression: the  T pairing F q 2 = F [s]/(s 2 + s + 1), F q 4 = F q 2 [t]/(t 2 + t + s). Input: P = (x P, y P ), Q = (x Q, y Q ) Output:  T (P, Q) u  x P + 1 f  u ¢ (u + x Q ) + y P + y Q + b + 1 + (u + x Q )s + t for i  1 to (m+1)/2 { u  x P, x P  p x P, y P  p y P g  u ¢ (x P + x Q ) + y P + y Q + x P + (u + x Q )s + t f  f ¢ g x Q  x Q 2, y Q  y Q 2 } return f (2 2m –1)(2 m –2 (m+1)/2 +1)

18. 18 USP/DCU © Paulo S. L. M. Barreto 2009 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.

19. 19 USP/DCU © Paulo S. L. M. Barreto 2009 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.

20. 20 USP/DCU © Paulo S. L. M. Barreto 2009 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.

21. 21 USP/DCU © Paulo S. L. M. Barreto 2009 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.

22. 22 USP/DCU © Paulo S. L. M. Barreto 2009 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)

23. 23 USP/DCU © Paulo S. L. M. Barreto 2009 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.

24. 24 USP/DCU © Paulo S. L. M. Barreto 2009 Advertisement: BN curves  E( F p ): y 2 = x 3 + b  #E = n = p + 1 – t  p(u) = 36u 4 + 36u 3 + 24u 2 + 6u + 1  n(u) = 36u 4 + 36u 3 + 18u 2 + 6u + 1  t(u) = 6u 2 + 1  t 2 – 4p = –3(6u 2 + 4u + 1) 2  j(E) = 0  min{k 2 N : n |  k (p)} = 12

25. 25 USP/DCU © Paulo S. L. M. Barreto 2009 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 F p 2 and F p respectively.  … allow for fast arithmetic in all groups involved.

26. 26 USP/DCU © Paulo S. L. M. Barreto 2009  … 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 Advertisement: BN curves

27. 27 USP/DCU © Paulo S. L. M. Barreto 2009 Questions? Thank You!