Cryptography Best Practices February 2019 Bart Preneel Outline Cryptography Best Practices • Architecture Prof. Bart Preneel • Network protocols COSIC, an imec lab at KU Leuven • Security APIs Bart.Preneel(at)esatDOTkuleuven.be • Key establishment: protocols, http://homes.esat.kuleuven.be/~preneel generation, storage February 2019 • Implementing digital signature schemes 1 2 © Bart Preneel. All rights reserved Symmetric vs. Asymmetric Architectures (1a) (sym.) Algorithms 2 • hardware costs: 1 K– • hardware costs: 12 • Point to point • Number of keys: 1 or n 100K gates K-1M gates • Local • Manual keying • performance: 10 • performance: 10 • Small scale Mbit/s – 1000 Gbit/s Kbit/s – 100 Mbit/s • keys: 64-256 bits • keys: 256-4096 bits Example: • blocks: 64-128-256 • blocks: 256-4096 bits ad hoc PAN or bits • power consumption: WLAN • power consumption: 1000-2000 μJ/bit 3-30 μJ/bit • postquantum: keys of 10-500 Kbyte 3 n nodes 4 Architectures (2a) (sym.) Architectures (3a) (sym.) • Centralized • Number of keys: n • Centralized • Number of keys: n + 1/session • Small or large scale • ! Central database: risk + • Small or large scale • Manual keying big brother • Manual keying • ! Central database: risk + big • Non-repudiation of origin? brother (physical assumptions) • Non-repudiation of origin? (physical assumptions) Example: WLAN, e-banking, GSM Example: LAN (Kerberos) n nodes 5 n nodes 6 1 Cryptography Best Practices February 2019 Bart Preneel Architectures (4a) (sym.) Architectures (5a) (sym.) • Decentralized • Number of keys: n + N2 • Centralized • Number of keys: n + N • Large scale • Risks? • Trust • Large scale • Hard to manage • Hierarchy Example: credit Example: network card and ATM of LANs, GSM, 3G, 4G n + N nodes 7 n + N nodes 8 Architectures (1b) (asym.) Architectures (2b) (asym.) • Point to point • No CA (e.g. PGP) • Centralized • Reduced risk • Worldwide • Large or small scale • Non-repudiation of origin • Small networks Example: P2P, international Example: B2C organizations e-banking n nodes 9 n nodes 10 Architectures (3b) (asym.) Architectures (4b) (asym.) • Decentralized • Key management • Centralized • Reduced risk • Large scale architecture? • Small or large scale • Non-repudiation of origin • (Open) • Trust Example: B2B, Example: B2B GSM interoperator and e-ID communication n nodes 11 n + N nodes 12 2 Cryptography Best Practices February 2019 Bart Preneel Architectures (5b) (asym.) When asymmetric cryptology? • Centralized • Open • if manual secret key installation not • Large scale feasible (also in point-to-point) • Hierarchy • open networks (no prior customer relation or contract) • get rid of risk of central key store Example: credit • mutually distrusting parties card EMV – strong non-repudiation of origin is needed • fancy properties: e-voting Important lesson: on-line trust relationships n + N nodes 13 should reflect real-word trust relationships14 EMV Static Data Authentication (SDA) EMV: dynamic/combined data authentication CERTISS Private Public Key CA (PISS Key certified SCA PCA with SCA) EPI Three layers: Private Public Key EPI Key Issuer Acquirer SISS PISS Issuers Issuer Issuer Issuer Static Card Cards Issuer data IC Distributed to Acquirer (Resides in Terminal) PCA IC Card POS15 Device 16 Certificate for dynamic data EMV Combined Data Authentication authentication of a credit card CERT ISS Private Public Key (PISS Key Unique name owner certified SCA PCA DN: cn=Jan Peeters, with SCA) EPI o=KBC, c=BE Unique serial number Serial #: 8391037 CERTIC Private Public Key Validity period (PIC Key Start: 3/12/18 1:00 certified Issuer SISS PISS Acquirer End: 4/12/21 12:01 Revocation information with SISS) CRL: cn=RVC, o=EMV, c=BE Public key Private Public Key Static Card Key data Key: IC P Name of issuing CA SIC IC Distributed to Acquirer (Resides in Terminal) CA’s Digital signature on the CA DN: o=EMV, c=BE certificate Authenticate and Sign Transaction with SIC PCA 17 IC Card POS18 Device 3 Cryptography Best Practices February 2019 Bart Preneel Warning about EMV Network protocols http://www.cl.cam.ac.uk/research/security/banking/nopin/oakland10chipbroken.pdf • Pin checking and authentication are not coupled • EMV PIN verification “wedge” vulnerability S.J. Host Host Murdoch, S. Drimer, R. Anderson, M. Bond, IEEE Security Application Application S/MIME & Privacy 2010 Presentation Presentation Session Session Transport Router Transport TLS/SSL Network Network Network IPsec Data link Data link Data link PPTP, Physical Physical Physical L2TP 19 20 Where to put security? Where to put security? (2) • Application layer: From: [email protected] – closer to user To: [email protected] – more sophisticated/granular controls Subject: Re: Can you meet me on Monday at – end-to-end 3pm to resolve the price issue? – but what about firewalls? • Lower layer: This proposal is acceptable for me. – application independent -- Bob – hide traffic data – but vulnerable in middle points • Combine? 21 22 Security APIs Master key/data key • Security module controls access to and • Load master 3DES key KM (tightly controlled) processing of sensitive data • Load data key: – executes cryptographic commands, e.g. PIN 3DES (K1)|| 3DES (K2)|| 3DES (K3) checking, encryption,… KM KM KM • Send plaintext P and ask for encryption I/O -1 DESK1(DES K2( DESK3(P))) Security module Host DES DES-1 DES %^C& hardware or software P @&^( network Security API 23 1 2 3 24 4 Cryptography Best Practices February 2019 Bart Preneel Master key/data key (2) Control vectors in the IBM 4758 (1) • Load master 3DES key KM (tightly controlled) • Potted in epoxy resin • Load corrupted data key: • Protective tamper-sensing membrane, DES (K1)|| DES (K1)|| DES (K1) KM KM KM chemically identical to potting compound • Send plaintext P and ask for encryption -1 • Detectors for temperature & X-Rays DESK1(DES K1( DESK1(P))) = DESK1(P) • “Tempest” shielding for RF emission • Low pass filters on power supply rails DES DES-1 DES %^C& • Multi-stage “latching” boot sequence P @&^( = STATE OF THE ART PROTECTION! 1 1 1 25 26 IBM 4758 Features of the IBM 4758 • Control vector: type (e.g., PIN, data, MAC) store key of type type as E Km + “type” (k) – Output of encryption with key of type “PIN” is never allowed to leave the box – Output of encryption with key of type data, MAC, … may leave the box • High security master key import: 3 shares – Import Km as KmA + KmB + KmC 27 28 Master key import Fraudulous import Km = Km + Km Km C C KmA KmB KmC A B “data” – “PIN” 1 2 Km = KmA + KmB + KmC Km* = KmA + KmB + KmC* = Km + “data” – “PIN” 29 30 5 Cryptography Best Practices February 2019 Bart Preneel The attack Lessons learned: security APIs Transport PIN key k from box 1 to box 2 • Complex – 150 commands 1. Encrypt on box 1, type PIN: • Need to resist to insider frauds x = E (k) • Hard to design – can go wrong in many Km + “PIN” ways 2. Decrypt on box 2, type data: • Need more attention D Km* + “DATA” (x) = D Km + “PIN” (x) = k Further reading: Mike Bond, Cambridge The system now believes that k is a key to University decrypt data, which means that the result will http://www.cl.cam.ac.uk/users/mkb23/research.html be output (PINs are never output in the clear) 31 32 “Efficient padding oracle attacks on The secure hardware delusion cryptographic hardware” (PKCS#11 devices) [Bardou+ 12] most attacks take less than 100 milliseconds e.g. August 2011 Diginotar: target Iranian opposition Device PKCS#1v1.5 CBC pad Ceci n’est pas token session token session Aladdin eTokenPro X X X X un HSM Feitian ePass 2000 OK OK N/A N/A Feitian ePass 3003 OK OK N/A N/A Gemalto Cyberflex X N/A N/A N/A TLS RSA Securid 800 X N/A N/A N/A Safenet iKey 2032 X X N/A N/A SATA dKey OK OK OK OK Siemens CardOS X X N/A N/A (89 secs) Key establishment protocols: Key management subtle flaws • Key establishment protocols • Person-in-the middle attack • Key generation – Lack of protected identifiers • Key storage • Reflection attack • Key separation (cf. Security APIs) • Triangle attack 35 36 6 Cryptography Best Practices February 2019 Bart Preneel Attack model: Person-in-the middle attack on Diffie- Needham and Schroeder [1978]: Hellman • Eve shares a key k1 with Alice and a key k2 We assume that the intruder can interpose with Bob a computer in all communication paths, • Requires active attack and thus can alter or copy parts of messages, replay messages, or emit false material. While this may seem an extreme view, it is the only safe one x1 x2 when designing authentication protocols. y1 y2 k1 =( y1) x1 =( x1)y1 k2 =( y2) x2 =( x2)y2 37 38 Entity authentication Entity authentication: reflection attack Eve does not know K and wants to Alice and Bob share a secret K impersonate Bob K K n K A nA nA EK(n||nA’) EK(nA||nB) EK(nA||nA’ =nB) nB 39 40 nB Needham-Schroeder (1978) Lowe’s attack on Needham-Schroeder (1995) Alice and Bob know each other’s public key PA and PB • Alice thinks she is talking to Eve • Bob thinks he is talking to Alice S SB SA SB A Derive a EPE(nA||A) EPB(nA||A) EPB(nA||A) session key EPA(nB||nA) EPA(nB||nA) EPA(nB||nA) k from nA||nB EPE(nB) EPB(nB) EPB(nB) 41 Eve 42 7 Cryptography Best Practices February 2019 Bart Preneel Lowe’s attack on Needham-Schroeder (1995) Lessons from Needham-Schroeder (1995) • Eve is a legitimate user = insider attack • Fix the problem by inserting B in message 2 • Prudent engineering practice (Abadi & Needham): include names of principals in all messages SA SB • IKE v2 – plausible deniability: don’t include name of correspondent in signed messages: http://www.ietf.org/proceedings/02nov/I-D/draft-