Скачать презентацию Pairings in Real Life Paulo S L M Скачать презентацию Pairings in Real Life Paulo S L M

e9578248ea7eff13501f5b0f09b6af07.ppt

  • Количество слайдов: 27

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

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

Motivation o Our goal: sample government, financial and general business necessities that can be Motivation o Our goal: sample government, financial and general business necessities that can be addressed with pairings. o When and how to use pairings in practice: case studies. o Where do we go next? © Paulo S. L. M. Barreto 2009 USP/DCU 3

Case study #1 o Tax payment authentication. n Government of São Paulo, Brazil. n Case study #1 o Tax payment authentication. n Government of São Paulo, Brazil. n > 40£ 106 inhabitants, 1/3 of GDP. o Previous system (< 2001): n Mechanical, non-cryptographic authentication system (authenticating printer). n Manual verification, requiring a trusted user. o Frauds! n Government admitted to 5% of tax payment evasion out of a $500£ 106 gross monthly tax revenue. © Paulo S. L. M. Barreto 2009 USP/DCU 4

Requirements o Automatic process, without manual intervention. o Open specification, unencumbered by patents. o Requirements o Automatic process, without manual intervention. o Open specification, unencumbered by patents. o Public-key scheme with security level roughly equivalent to RSA-1024. o Authentication tag must be printable on two alphanumerical lines (320 bits). o Half of the available space is occupied by context information (user id, bank id, amount paid, date, etc). o Volume of ~2– 4£ 106 authentications a month must be handled on a single Pentium II 450 MHz PC. © Paulo S. L. M. Barreto 2009 USP/DCU 5

Assessment o 160 -bit signatures: (EC)DSA won’t do. o Available options at the time: Assessment o 160 -bit signatures: (EC)DSA won’t do. o Available options at the time: n n n CFS OP/BLS (preprint) HFE schemes o Would any of these be acceptable? © Paulo S. L. M. Barreto 2009 USP/DCU 6

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

Digression: BLS signatures o Setup: e: G 1 £ G 2 GT, H: {0, Digression: BLS signatures o Setup: e: G 1 £ G 2 GT, H: {0, 1}* G 1. o Key pair: (s random, V s. Q G 2). o Signature: s. H(m) G 1. o Verification: accept (m, ) e( , Q) = e(H(m), V). o Explanation: n n e( , Q) = e(s. H(m), Q) e(H(m), V) = e(H(m), s. Q) © Paulo S. L. M. Barreto 2009 USP/DCU = e(H(m), Q)s. 8

Solution and results o BLS was the only plausible choice. n Performance still fell Solution and results o BLS was the only plausible choice. n Performance still fell short of the reqs by one order of magnitude. o BKLS/GHS variant of Miller’s algorithm, use of an MNT 6 curve and several other optimizations increased performance by a factor of 55 (even more afterwards). © Paulo S. L. M. Barreto 2009 USP/DCU 9

Solution and results o All reqs satisfied: n CPU >80% idle in initial version, Solution and results o All reqs satisfied: n CPU >80% idle in initial version, now >99%. n There was even room for business rule improvements. o Government reported that frauds fell to 0% (sic), increasing tax revenue from $500£ 106 to $1. 5£ 109 (sic). o Still in use today – no further modification needed. © Paulo S. L. M. Barreto 2009 USP/DCU 10

Case study #2 o Wireless sensor networks (WSN). o Large number of applications: n Case study #2 o Wireless sensor networks (WSN). o Large number of applications: n n Weather monitoring. Remote medical monitoring. Inventory control. Battlefield management. o Key agreement protocol needed for node- to-node secure communication. © Paulo S. L. M. Barreto 2009 USP/DCU 11

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

Assessment o A typical authenticated key agreement protocol (e. g. HMQV-p) involves 2– 3 Assessment o A typical authenticated key agreement protocol (e. g. HMQV-p) involves 2– 3 passes of message exchanges between the involved parties. n Very bad for WSN. o Computing a pairing is a very processor-intensive operation: n n Roughly one order of magnitude more than elliptic curve arithmetic. May be a minor concern in WSNs. © Paulo S. L. M. Barreto 2009 USP/DCU 13

Assessment o Identity-based techniques improve the scenario. o Sakai-Ohgishi-Kasahara authenticated key agreement protocol (SOK): Assessment o Identity-based techniques improve the scenario. o Sakai-Ohgishi-Kasahara authenticated key agreement protocol (SOK): n n 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! © Paulo S. L. M. Barreto 2009 USP/DCU 14

Digression: SOK protocol o Setup: e: G £ G GT, H: {0, 1}* G. Digression: SOK protocol o Setup: e: G £ G GT, H: {0, 1}* G. n Symmetric pairing: e(A, B) = e(B, A). o KGC key pair: (s random, V s. P G). o ID-based private key: PA s. H(IDA) G. o Authenticated shared key: n KAB = e(PA, H(IDB)) = e(PB, H(IDA)) GT. o Pros & Cons: purely offline protocol comes at the price of having a fixed shared key. © Paulo S. L. M. Barreto 2009 USP/DCU 15

Assessment o Caveat: some choices may be better than others. o How about generic Assessment o Caveat: some choices may be better than others. o How about generic pairing parameters, e. g. BN curves? o Obstacles to this approach: n Code/memory reqs may not fit available space. n Slow processing may be annoying even if acceptable. n Overkill anyway (“killing a flea with an atomic bomb”). © Paulo S. L. M. Barreto 2009 USP/DCU 16

Digression: the T pairing Fq 2 = F [s]/(s 2 + s + 1), Digression: the T pairing Fq 2 = F [s]/(s 2 + s + 1), Fq 4 = Fq 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 px. P, y. P py. P g u¢(x. P + x. Q) + y. P + y. Q + x. P + (u + x. Q)s + t f f¢g x Q 2 , y Q 2 } 2 m m (m+1)/2+1) return f (2 – 1)(2 – 2 © Paulo S. L. M. Barreto 2009 USP/DCU 17

Solution and results o The T pairing on binary supersingular curves is the most Solution and results o The T pairing on binary supersingular curves is the most efficient choice for a WSN. n n Contrary to what may be expected from a general-purpose processor. Aranha et al, CHi. LE’ 2009. o Supersingular varieties limit achievable security level: so what? n Typical security reqs on a WSN not too high: ephemeral data points to be consolidated. © Paulo S. L. M. Barreto 2009 USP/DCU 18

Case study #3 o Secure SMS messaging: n Business information exchange. n Micropayments. o Case study #3 o Secure SMS messaging: n Business information exchange. n Micropayments. o Heterogeneous, ad-hoc scenario: n Servers for administrative tasks. n “High”-power mobile phone processors. n “Low”-power mobile phone processors. o Choice of parameters depends not only on the technical bottlenecks but on average “customer satisfaction” as well. © Paulo S. L. M. Barreto 2009 USP/DCU 19

Requirements o Raw space: 140 bytes per message. o One SMS exchange per pair Requirements o Raw space: 140 bytes per message. o One SMS exchange per pair of users is acceptable for “certificate exchange”. o 85% of raw space must be available for a purely encrypted message, and 70% for an encrypted and signed message. o Any mobile phone with an API should be allowed. o Must not be (purely) identity-based. © Paulo S. L. M. Barreto 2009 USP/DCU 20

Assessment o Usual certificates take 2 -4 Ki. B (15– 30 SMS messages per Assessment o Usual certificates take 2 -4 Ki. B (15– 30 SMS messages per user pair just to exchange certificates). o Conventional crypto overhead of several SMS messages per user message. o For a strict space of 140 bytes, constraints imply max overhead of ~20 bytes for pure encryption and ~40 bytes for encryption and signature. © Paulo S. L. M. Barreto 2009 USP/DCU 21

Solution and results o Self-certified pairing-based procotol tightly addresses reqs. n n Pairing computation Solution and results o Self-certified pairing-based procotol tightly addresses reqs. n n 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. o Other solutions? n Certificateless protocol would do as well. n New protocols with interesting properties, e. g. Fiore and Gennaro, e. Print 2009/174 (IBDH, no pairings except in security proofs) © Paulo S. L. M. Barreto 2009 USP/DCU 22

Overall analysis o All case studies involve more or less constrained platforms where pairings Overall analysis o All case studies involve more or less constrained platforms where pairings should naively be too inefficient to use. o Yet the intended high-level, real-world application was only feasible because of pairings! o Moral: do not be afraid of using pairings – they look complicated and expensive, but are very useful and effective. © Paulo S. L. M. Barreto 2009 USP/DCU 23

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

Advertisement: BN curves o … facilitate pairings at the 128 -bit security level. o Advertisement: BN curves o … facilitate pairings at the 128 -bit security level. o … are good for all pairing applications, including short signatures. o … support a sextic twist, so the Q and P parameters of the *ate pairing are defined over Fp 2 and Fp respectively. o … allow for fast arithmetic in all groups involved. © Paulo S. L. M. Barreto 2009 USP/DCU 25

Advertisement: BN curves o … support pairing compression. o … are friendly to optimal Advertisement: BN curves o … support pairing compression. o … are friendly to optimal pairings (1/4 length loop). o … are plentiful and easily found. o … I could go on… o … thanks to Mike Scott from whom I stole the advertisement slides © Paulo S. L. M. Barreto 2009 USP/DCU 26

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