Practical Secure Two-Party Computation and Applications Lecture 4: - PowerPoint PPT Presentation

Practical Secure Two-Party Computation and Applications Lecture 4: Hardware-Assisted Cryptographic Protocols Estonian Winter School in Computer Science 2016

Motivation 2

Two Areas Cryptographic Protocols Secure Hardware • strong security + privacy guarantees • provides secure (key) storage • often low performance 
 • + trusted execution environment • is getting cheaper (e.g., due to high communication) 3

Cryptographic Protocols + Hardware ? § Hardware Accelerators § allow to speed up computations § parallelism (e.g., GPU, FPGA, Cell Processor, … ) § Secure Hardware § possibilities beyond SW-only § secure storage § secure execution environment § can be used to construct more efficient protocols § less computation § less communication 4

Hardware-Assisted Cryptographic Protocols sends token T Sender S Receiver R protocol Π § Where do we use secure HW tokens? § banking, SIM cards, pay-tv, passports, health cards, … § Why do we use HW tokens? § SW alone often not secure/efficient/sufficient/ … § Benefits for practice? § security, efficiency, unclonability, (money), … 5

Overview of this lecture Hardware Tokens Hardware Tokens as Setup Assumption Hardware-Assisted Cryptographic Protocols in Practice in Theory Special Purpose Protocols Generic Protocols Oblivious Transfer Private Set Intersection Yao GMW 6

Hardware Tokens in Practice 7

Popular Secure Hardware § Smartcards § Contact cards (e.g., Java Cards) § Contactless cards (e.g., Mifare DESFire) § Cryptographic Coprocessors § Special-purpose secure co-processors 
 (e.g., Trusted Platform Module TPM) § General-purpose and user-programmable 
 secure co-processors (e.g., IBM 4765) 8

Overview: Smart Card Technology § Memory-Only (e.g., calling cards) § simple data storage (read/write or read-only) § usually hard-wired authentication schemes (e.g., using PIN) § Wired Logic (e.g., MIFARE-based electronic tickets) § Hard-wired state machine for encrypted and/or authenticated memory access § Multi-application support § Static file system § Contact or contactless interface § Secure Microcontroller (e.g., JavaCard) § Microcontroller, operating system, read/write memory § Computation and file system managed by operating system § Contact and/or contactless interface 9

Secure Microcontroller Smart Cards Read5Only(Memory((ROM)((>(256(KB)( Cryptographic(Co5Processor( !" !Contains!opera6ng!system!and!applica6ons! !" !Symmetric!Encryp6on!(typically!!DES,!3DES!or!AES)! !" !Ini6alized!during!manufacturing!of!the!device! !" !Cryptographic!hashing!(typically!SHA"1)! !" !MAC!(typically!CBC"MAC)! !" !Public"key!encryp6on!(typically!RSA/ECC)! Non5Vola>le(Memory((NVM)((>(128(KB)( !" !Signature!(typically!RSA/ECC)! !" !Read/write!memory!holding!data!aUer!power!off! !" !Stores!user!data!(e.g.,!device!serial!number,! True(Random(Number(Generator((TRNG)( !applica6on!data,!cryptographic!secrets)! !"!E.g.,!for!the!genera6on!of!keys!and!nonces! !" !Supports!only!limited!number!of!writes!(>!50.000)! !" !E.g.,!EEPROM!and/or!Flash! Protec>on(against(physical(aAacks((e.g.,(against( side5channel(and/or(invasive(aAacks)( !" !Typically!compliant!to!FIPS!140"2! Random(Access(Memory((RAM)((>(25(KB)( !" !OUen!cer6fied!by!Common!Criteria! !" !Read/write!memory!losing!data!aUer!power!off! !" !Includes!environmental!sensors!(e.g.,!to!detect! !" !Stores!temporary!data!during!opera6on! !voltage,!frequency,!temperature!varia6ons)! Central(Processing(Unit((CPU)( Counters( !" !8,!16!or!32!bit! !" !E.g.,!for!memory!access!control! Communica>on(Interface( !" !Contact!interface!(1.5!–!12!MB/s)! !" !Contactless!interface!(4!–!848!KB/s)! 10

Trusted Platform Module (TPM) § Current implementation is a cryptographic co-processor § Hardware-based random number generation § Small set of cryptographic functions § Key generation, signing, encryption, hashing, MAC § Offers additional functionalities § Registers for secure platform integrity measurement and reporting § Secure storage (ideally tamper-resistant) § Embedded into the platform’s motherboard § Acts as a “Root of Trust” § TPM must be trusted by all parties § Many vendors already ship their platforms with a TPM 11

Programmable Secure Coprocessor: IBM 4758 § General-purpose secure coprocessor § Hard- and firmware maintained by IBM § User can run own operating system and applications § True Random Number Generator § Symmetric Crypto in HW (e.g., AES, SHA) § Modular Arithmetics in HW (e.g., RSA, DSA) § Security Functions § Integrity self-check (processor internally performs secure boot) § Hardware-protected storage including hardware-based access control § Tamper-responding hardware design § Sensors detect tampering (e.g., temperature, voltage, radiation variations) § Automatically erases secrets when tampering is detected § Certified under FIPS 140-2 Level 4 (highest level of security) 12

How Secure is Secure Hardware? § Attacks [Kömmerling,Kuhn Smartcard’99] § Micro-probing: Obtain direct physical access to the device’s memory § Side-channel attacks: Analyze analog characteristics of all supply and interface connections and electromagnetic radiation of the device § Fault injection attacks: Observe device’s behavior under abnormal conditions (e.g., unspecified supply voltage, operating temperature, focused ion beam). § Example: Hardware Attack on TPM chip [Tarnovsky BlackHat’10] § Protection Mechanisms § Against side-channel attacks § Randomized program flows § Obfuscation of input data and intermediate results § Against microprobing and fault injection attacks Focused Ion Beam Microscope § Tamper-detection mechanisms (e.g., temperature, voltage, 
 frequency sensors) that erase secret data on tampering attempts ➩ Security of Secure Hardware is always a Trade-Off 13

Hardware Tokens in Theory 14

State and Type § Stateless Tokens (read only) § initialized once (e.g., with key) § do not hold any long-term state between sessions § less possibilities for HW attacks (e.g., no counter) § more difficult protocol design § Stateful Tokens (read/write) § hold long-term state between sessions § need secure non-volatile memory § simple HW functionality: 
 secure monotonic counter § Capabilities and resources § usually very small amount of secure memory § symmetric crypto vs. public key crypto, ... 15

Trust Models § I trust my own token: § use as accelerator (e.g., GPU,FPGA, … ) § All tokens are “good” (trusted by both parties): § Similar to Common Reference String Model where Trusted Third Party (TTP) generates well-formed tokens instead of well-formed CRS § I don’t trust your token (trusted by sender only): § Receiver does not trust token issued by Sender 
 (as Receiver does not trust Sender either) § Sender S could send cheating token (or infected with HW Trojan) § I don’t trust my own token (trusted by nobody): § Receiver could break into the token and extract secrets by getting around physical protection mechanisms (e.g., side-channel attacks) 16

Adversary Models § Semi-honest (honest-but-curious, passive): § all parties honestly follow protocol § adversary tries to learn additional information 
 from the corrupted parties’ state (including messages seen) § appropriate for many real life applications (e.g., protect against insider attacks) § Covert: § corrupted parties deviate from protocol § cheating detected with constant probability (e.g., ½ ) § Malicious (active): § corrupted parties deviate from protocol § adversary can succeed with at most negligible probability (e.g., 2 − 80 ) § Universal Composability: § security against active adversaries 
 + secure universal protocol composition (sequential & concurrent) 17

Hardware Tokens as Setup Assumption 18

Overcome Impossibility Results of UC The Universal Composability (UC) Framework [Canetti FOCS’01] § Security against active adversaries 
 + secure universal protocol composition 
 (sequential & concurrent) § Impossibility result: No non-trivial two-party functionality can be UC- realized in the plain model (without any trusted setup) § Setup Assumption required to overcome impossibility result 19

Setup Assumptions for UC Find minimal but “practical” assumptions for UC § Common Reference String (CRS) 
 [Canetti,Fischlin CRYPTO’01] Trust in 
 § Public-Key Registration Service 
 Third Party [Barak,Canetti,Nielsen,Pass FOCS’04] § Government-issued “Signature Cards” 
 [Hofheinz,Müller-Quade Moraviacrypt’05] Trust in 
 Technology § Tamper-proof Hardware Tokens 
 (trusted by issuer only): next slides … 20

Crypto Founded on Tamper-Proof HW § Sender constructs a hardware token implementing any desired (polytime) functionality (e.g., programmable smartcard) § Receiver and Adversary can use token as black box only, 
 i.e., observe its input/output characteristics § Trust model § Token not trusted by Receiver § Token communicates with Receiver only § not to outside world § or only up to a certain number of bits to outside world § Different Models § Symmetric (both parties construct a tamper-proof token) § Asymmetric (only one party constructs a tamper-proof token) 21