Masaryk U. – related research, interest Laboratory of security and applied cryptography Lab head: Vashek Matyáš Petr Švenda Masaryk University, Brno, Czech Rep.

Masaryk U. – related research, interest The team 4 faculty members full-time ●and 2 postdocs 4 PhD students, 15+ MSc 2-4 faculty members in relevant areas Dedicated lab with basic biometric, smartcard, mobile, wired and WiFi (security) equipment, HSMs, sensor nodes, oscilloscopes…

Masaryk U. – related research, interest Ongoing/past projects Department of Home Affairs ●cryptographic protocols, privacy, intrusion detection in wireless sensor networks – applied research project National Security Authority ●long-term cooperation in the areas of secure H/W, smartcards and related applications, including crypto protocols Czech Science Agency and industry projects ●mobile devices, tokens, biometrics, code audits… EU PICOS (Privacy and Identity Management for Community Services) (STREP) ●mobile privacy preserving services for communities ●requirements (gaming community), architecture, eval. & assurance EU FIDIS Network of Excellence (EC) ●identity, identification, privacy ●autentication – PKI, biometrics, tokens, protocols

Main topics of interest Cryptographic hardware ●mainly smart cards Wireless Sensor Networks ●design and practical implementation of network wide protection layer (privacy, IDS, key distribution) Random number generators ●practical testing: mobile phones, smart cards Evolutionary algorithms + BOINC ●utilization of distributed computation for other areas Masaryk U. – related research, interest

Masaryk U. – related research, interest Main topics of interest – secure hardware Laboratory equipment capable to ●power analysis of smart cards ●fault induction attacks (power&data glitch) ●bytecode level reverse engineering Source code analysis & software-level protections ●automatic source code transformation (CesTa) Design & implementation of smart card protocols ●advanced schemes utilizing on smart cards ●(micro-)payment schemes

Masaryk U. – related research, interest Cryptographic Hardware Security Projects mainly for Czech NSA ●How to select most suitable smart card? ●How to test large batch for same hardware? ●How to detect potential backdoor? ●How to fix problems with hardware in software? Projects with Czech provider of ePassports and citizen ID cards ●How to let user to confirm transcation amount? ●Source code audits

Masaryk U. – related research, interest Basic setup for power analysis Smart card Smart card reader Inverse card connector Oscilloscope Resistor ohm Probe

Masaryk U. – related research, interest More advanced setup for power analysis Ethernet Tested smartcard External power supply SCSAT04 measurement board

Database of common operations Power trace of DES, AES, EEPROM, write RAM, RSA, MD5/SHA1/SHA256 … GlobalPlatform SCP’0x, PIN verification… Masaryk U. – related research, interest

Masaryk U. – related research, interest Bytecode - situation with current SC Tested 10 different families from 4 manufactures ●3 with clearly visible bytecode and separators ●3 with visible bytecode, but no separators ●1 with partially visible bytecode ●3 without visible bytecode Caused by used type of the main processor

Masaryk U. – related research, interest Reverse engineering of Java Card bytecode Goal: obtain code back from smart card ●JavaCard defines around 140 bytecode instructions ●JVM fetch instruction and execute it (source code) m_ram1[0] = (byte) (m_ram1[0] % 1); (bytecode) getfield_a_this 0; sconst_0; baload; sconst_1; srem; bastore; (power trace) compiler oscilloscope

Masaryk U. – related research, interest Reverse engineering Target card sadd; sstore 4; sload 4; sconst_1; aload_1; sload 4; sadd; sadd unknown; sload sconst sload sconst

Masaryk U. – related research, interest (bytecode) sload_1; ifeq_w L2; L1: getfield_a_this 0; sconst_0; bastore; goto L3; L2: getfield_a_this 0; sconst_0; sconst_1; bastore; goto L3; L3: … Conditional jumps may reveal sensitive info keys, internal branches, … (source code) if (key == 0) m_ram1[0] = 1; else m_ram1[0] = 0; compiler oscilloscope (power trace, k != 0) (power trace, k == 0)

Masaryk U. – related research, interest Incorrect checksum Incorrect MAC External Authenticate

FITKit logger and manipulator Masaryk U. – related research, interest

Masaryk U. – related research, interest Automated code transformation CesTa project

Masaryk U. – related research, interest CesTa - main design goals 1.Enhanced security on real applets ●fix what is wrong, add preventive defenses 2.Source code level & auditability ●trust, but verify 3.Complexity is hidden ●clarity of original code 4.Flexibility & Extensibility ●protect against new threats ●protect only what HW does not

Masaryk U. – related research, interest CesTa – basic scheme Write code once, apply only what needed

Masaryk U. – related research, interest CesTa project – current state JavaCard transformations, SC.NET in development Several non-trivial transformations implemented ●low level IfSwitchReplacement (replacement rule) ●generic ShadowVariables (replacement rule) ●generic ValidateStateTransitions (replacement rule) ●generic CheckTransactions (analysis rule) Tested on real (bigger) applets ●JOpenPGPCard, CardCrypt/TrueCrypt, crypto software impl… Transformations can be provided by independent labs ●modular design, open source

Summary 1.Obtain some info from power trace ●JC RE, OpenPlatform operation powertrace 2.Make additional testing ●APDUPlay/FITKitlogger packet manipulation ●Power glitch fault induction ●Combined with power trace 3.Inspection of interface and protocols used ●SACC, APDUPlay ●Often combined with power trace (hidden code detection) 4.Fix problems found with automatic source code transformations ●CesTa project Masaryk U. – related research, interest

Masaryk U. – related research, interest

Backup slides Masaryk U. – related research, interest

Masaryk U. – related research, interest IF_SWITCH transformation Conditional jump (IF THEN ELSE) leaks argument ●IP++ or IP = IP + branch_offset SWITCH also leaks, but have multiple branches ●attacker can still distinguish first and second branch ●but not between second and third branch ●jump executed in both cases ●IP = IP + branch2_offset or IP = IP + branch3_offset Basic idea ●replace IF THEN ELSE -> SWITCH

Masaryk U. – related research, interest IF THEN ELSE still present, but randomized ●attacker can distinguish then and else branch ●but not case 0: and case 1: branch IF_SWITCH transformation – robust version Assumption: comparison and assignment is not leaking Random branch will be taken

Masaryk U. – related research, interest IF_SWITCH template unique ID for expression variable (e.g., expr_res13) jump logical expression (e.g., key == 0) content of THEN branch (e.g., m_ram[0] = 5;) content of ELSE branch (e.g., m_ram[0] = 7;)

Masaryk U. – related research, interest Another attack – fault induction Attacker can induce bit faults in memory locations ●power glitch, flash light, radiation... ●harder to induce targeted then random fault Protection with shadow variable ●every variable has shadow counterpart ●shadow variable contains inverse value ●consistency is checked every read/write to memory Robust protection, but cumbersome for developer if (a != ~a_inv) Exception(); a = 0x55; a_inv = ~0x55; if (a != ~a_inv) Exception(); a = 0x13; a a_inv

Masaryk U. – related research, interest Applet state transition enforcement Applet security states controlled usually ad-hoc ●if (adminPIN.isValidated() && bSecureChannelExists) … ●unwanted (unprotected) paths may exist Possible solution ●model state transitions in inspectable format (DOT (GraphViz) ●automatically generate code for state transitions ●check appropriate states in sensitive methods

Masaryk U. – related research, interest Applet state transition - example

Masaryk U. – related research, interest Check transactions Transactions can breach applet security ●e.g., decreased PIN counter value is rolled back CesTa can detect possible problems in code ●warning is generated