Software Hardening & FIPS 140 Eugen Bacic & Gary Maxwell September 27th, 2005

Software vs. Hardware Software is preferable to hardware due to cost & flexibility Plus: Ease of deployment Ease of upgrade Diversity Generality Malleability

Barriers to Software Solutions Environment Crypto Culture Attacker Expertise Hardware good, software bad: Tampering is more difficult to hide with hardware Harder to “turn” hardware away from its intended purpose Reliability & redundancy Cracker sophistication needs to be higher Independent of host applications Cracker opportunities typically require physical access

Meeting FIPS 140 Level 3 Cryptographic module ports and interfaces Notion of a “data port” nebulous in software Interfaces may be viable points (i.e., APIs) Can be expected of “good programming practices” Roles, Services, & Authentication Identity-based operator authentication Two factor authentication should suffice Software module should be self-authenticating as well Design Assurance High-level language implementation is standard software practice

Meeting FIPS 140 Level 3 Physical Security Parts are hardware specific Anti-debug technologies would need to be deployed Obfuscation can meet many of the requirements Some are too hardware specific and would have to be ignored Must remember that there are a lot of reverse engineering tools, and so must ensure software crypto solutions are adequately prepared Tamper detection hard when software can easily be replicated OS-level and OS-hardware interaction can help alleviate above

Meeting FIPS 140 Level 3 Operational Environment EAL3 requirement Can be met with EAL3 operating systems Cryptographic Key Management White-box cryptography resolves this issue EMI/EMC Software can manipulate EMI/EMC signals However, the bandwidth may be too low to provide sufficient attack significance Furthermore, white-box cryptography with its use of consistent lookup tables should aid in resisting timing attacks

Circumvention Research Interesting research coming out of Canada Wurster’s Generic Attack Hyper-Threading Vulnerability Similarities in that unprivileged users can modify the execution stream of certain popular processors without detection: Difficult to detect attack code Feasible even where emulator-based attacks fail Attack code is generic and not program dependent Further research necessary to determine the true threats posed At present it seems there are no viable solutions to the above threats

Conclusion Notwithstanding current circumvention research, efforts must be made in examining viable software crypto standards Obfuscation and other tamper resistant techniques should be examined Research must be pursued that accurately defines: What is necessary for Level 3 software crypto Adequate tests for Level 3 crypto Impact of software crypto on the industry

Thank You! Eugen Bacic Chief Scientist Cinnabar Networks Inc.