Transcript Insert Title Here - Black Hat Briefings
Secure Hardware Design
Secure Hardware Design
The Black Hat Briefings July 26-27, 2000
Brian Oblivion, Kingpin [oblivion, kingpin]@atstake.com
Why Secure Hardware?
Embedded systems now common in the industry Hardware tokens, smartcards, crypto accelerators, internet appliances Detailed analysis & reverse engineering techniques available to all Increase difficulty of attack The means exist
Solid Development Process
Clearly identified design requirements Identify risks in the life-cycle Secure build environment Hardware/Software Revision control Verbose design documentation Secure assembly and initialization facility End-of-life recommendations Identify single points of failure Security fault analysis Third-party design review
Sources of Attack
Attacker resources and methods vary greatly
Resource
Time Budget ($) Creativity Detectability Target Number Organized Spread info?
Teenager
Limited <$1000 Varies High Challenge Many No Yes
Academic
Moderate $10K-$100K High High Publicity Moderate No Yes
Org. Crime
Large $100K+ Varies Low Money Few Yes Varies
Gov’t
Large Unknown Varies Low Varies Unknown Yes No Source: Cryptography Research, Inc. 1999, “Crypto Due Diligence”
Accessibility to Product
Purchase All attacks possible Evaluation Active, in-service Remote access Most attacks possible with risk of detection Most attacks possible No physical access
Attack Scenarios
System Enclosure Circuit Firmware
Attack Scenarios
System Initial experimentation & probing Viewed as a “black box” Can be performed remotely Bootstrapping attacks
Attack Scenarios
Enclosure Gaining access to product internals Probing (X-ray, thermal imaging, optical) Bypassing tamper-proofing mechanisms
Attack Scenarios
Circuit PCB design & parts placement analysis Component substitution Active bus and device probing Fault induction attacks 1 Timing attacks 2 Integrated circuit die analysis 3
Attack Scenarios
Firmware Low-level understanding of the product Obtain & modify intellectual property Bypass system security mechanisms Ability to mask failure detection
Attack Scenarios
Strictly
Firmware - no product needed!
Obtain firmware from vendor’s public facing web site Can be analyzed and disassembled without detection
What Needs To Be Protected?
Firmware binaries Boot sequence Cryptographic functionality (offloaded to coprocessor) Secret storage and management Configuration and management communication channels
System
System
Firmware Circuit Enclosure
Trusted Base
Minimal functionality – Trusted base to verify the integrity on firmware and/or Operating System – Secure store for secrets – Secrets never leave the base unencrypted – Security Kernel Examples of a Trusted Base – A single IC (some provide secure store for secrets) – May be purchased or custom built (Secure Coprocessor) – All Internals - circuit boards, components, etc.
– Entire trusted base resides within tamper envelope – Firmware – Security Kernel System
Security Kernel
Better when implemented in Trusted Base, but can function in OS System Enforces the security policy Ability to decouple secrets from OS Example: Cryptlib 4
Trusted Base example
Memory Mapped Bus CSOC Control Bus Bulk Transfer Bus External Memory Bus Data Memory (may be dual ported.) for bulk encrypt/decrypt Host Firmware Host Processor Main memory (DRAM) Communication Interface(s) System
Failure Modes
Determine how the product handles failures Fail-open or fail-closed?
Response depends on failure type Halt system Set failure flags and continue Zeroization of critical areas System
Management Interfaces
Do not include service backdoors!
Utilize Access Control Encrypt all management sessions SSH for shell administration SSL for web administration System
Firmware
System
Firmware
Circuit Enclosure
Firmware
Secure Programming Practice
Code obfuscation & symbol stripping Use compiler optimizations Remove functionality not needed in production Two versions of firmware: Development, Prod.
Remove symbol tables, debug info.
Secure Programming Practice
Buffer overflows 5 Highly publicized and attempted If interfacing to PC, driver code with overflow could potentially lead to compromise Firmware
Boot Sequence
Common Boot Model Flash (BIOS) (May be ROM) New or Overloaded functionality Time Hardware Reset
Trusted Boot Sequence
CSOC Common Boot Model Bootrom POST, Security Kernel Verify Bootrom and Flash Flash New or Overloaded functionality Verify Embedded OS Host System FlashDisk or Fixed Disk Embedded OS or state machine Verify Applications FlashDisk or Fixed Disk Applications Hardware Reset Host System FlashDisk or Fixed Disk Embedded OS or state machine Time FlashDisk or Fixed Disk Applications Firmware
Firmware
Run-Time Diagnostics
Make sure device is 100% operational all the time Periodic system checks Failing device may result in compromise
Firmware
Secret Management
Never leak unencrypted secrets out Escrow mechanisms are a security hazard If required, perform at key generation, in the physical presence of humans Physically export Key Encryption Key and protect Export other keys encrypted with Key Encryption Key
Firmware
Cryptographic Functions
If possible, move out of firmware …into ASIC Difficult to modify algorithm Cannot be upgraded easily Increased performance …into commercial CSOC or FPGA Can reconfigure for other algorithms May also provide key management Increased Performance Reconfiguration via signed download procedure (CSOC only)
Firmware
Field Programmability
Is your firmware accessible to everyone from your product support web page?
Encryption Compressing the image is not secure Encrypting code will limit exposure of intellectual property Code signing Reduce possibility of loading unauthorized code
Circuit
System Firmware
Circuit
Enclosure
Circuit
PCB Design
Remove unnecessary test points Traces as short as possible Differential lines parallel (even if on separate layers) Separate analog, digital & power GND planes Alternate power and GND planes
Circuit
Parts Placement
Difficult access to critical components Proper power filtering circuit as close to input as possible Noisy circuitry (i.e. inductors) compartmentalized
Physical Access to Components
Epoxy encapsulation of critical components Circuit Include detection mechanisms in and under epoxy boundary
Power Supply & Clock Protection
Set min. & max. operating limits Protect against intentional voltage variation Watchdogs (ex: Maxim, Dallas Semi.) dc-dc Converters, Regulators, Diodes Monitor clock signals to detect variations Circuit
Circuit
I/O Port Properties
Use unused pins to detect probing or tampering (esp. for FPGAs) - Digital Honeypot Disable all unused I/O pins
Programmable Logic & Memory
Make use of on-chip security features FPGA design Make sure all conditions are covered State machines should have default states in place Be aware of what information is being stored in memory at all times 6 (i.e. passwords, private keys, etc.) Prevent back-powering of non-volatile memory devices Circuit
Advanced Memory Management
Often implemented in small FPGA Bounds checking in hardware Execution, R/W restricted to defined memory DMA restricted to specified areas only Trigger response based on detection of “code probing” or error condition Circuit
Circuit
Bus Management
COMSEC Requirements Keep black (encrypted) and red (in-the-clear) buses separate Data leaving the device should always be black Be aware of data on shared buses
Enclosure
System Firmware Circuit
Enclosure
Enclosure
Tamper Proofing
Resistance, Evidence, Detection, Response Most effective when layered Possibly bypassed with knowledge of method
Tamper Proofing
Tamper Resistance Hardened steel enclosures Locks Encapsulation, potting Security screws Tight airflow channels, 90 o probing bends to prevent optical Side-effect is tamper evident Enclosure
Tamper Proofing
Tamper Evidence Major deterrent for minimal risk takers Passive detectors - seals, tapes, cables Special enclosure finishes Most can be bypassed 7 Enclosure
Tamper Proofing
Tamper Detection Ex: Temperature sensors Micro-switches Nichrome wire Flex circuit Radiation sensors Magnetic switches Pressure contacts Fiber optics Enclosure
Tamper Proofing
Tamper Response Result of tampering being detected Zeroization of critical memory areas Provide audit information Enclosure
Enclosure
RF, ESD Emissions & Immunity
Clean, properly filtered power supply EMI Shielding Coatings, sprays, housings Electrostatic discharge protection Could be injected by attacker to cause failures Diodes, Transient Voltage Suppressor devices (i.e. Semtech)
Enclosure
External Interfaces
Use caution if connecting to “outside world” Protect against malformed, intentionally bad packets Encrypt or (at least) obfuscate traffic Be aware if interfaces provide access to internal bus Control bus activity through transceivers Attenuate signals which leak through transceivers with exposed buses (token interfaces) Disable JTAG and diagnostic functionality in operational modes
In Conclusion…
As a designer: Think as an attacker would As design is in progress, allocate time to analyze and break product Peer review Third-party analysis Be aware of latest attack methodologies & trends
References
2.
3.
4.
5.
6.
7.
1.
Maher, David P., “Fault Induction Attacks, Tamper Resistance, and Hostile Reverse Engineering in Perspective,” Financial Cryptography, February 1997, pp. 109-121 Timing Attacks, Cryptography Research, Inc., http://www.cryptography.com/timingattack/ Beck, F., “Integrated Circuit Failure Analysis: A Guide to Preparation Techniques,” John Wiley & Sons, Ltd., 1998 Gutmann, P., Cryptlib, “The Design of a Cryptographic Security Architecture,” Usenix Security Symposium 1999, http://www.cs.auckland.ac.nz/~pgut001/cryptlib.html
Mudge, “Compromised Buffer Overflows, from Intel to SPARC version 8,” http://www.L0pht.com/advisories/bufitos.pdf
Gutmann, P., “Secure Deletion from Magnetic and Solid-State Memory Devices,” http://www.cs.auckland.cs.nz/~pgut001/secure_del.html
“Physical Security and Tamper-Indicating Devices,” http://www.asis.org/midyear-97/Proceedings/johnstons.html
Additional Reading
1.
2.
3.
4.
5.
6.
DoD Trusted Computer System Evaluation Criteria (Orange Book), 5200.28-STD, December 1985, http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html
Clark, Andrew J., “Physical Protection of Cryptographic Devices,” Eurocrypt: Advances in Cryptography, April 1987, pp. 83-93 Chaum, D., “Design Concepts for Tamper Responding Systems,” Crypto 1983, pp. 387-392 Weingart, S.H., White, S.R., Arnold, W.C., Double, G.P., “An Evaluation System for the Physical Security of Computing Systems,” Sixth Annual Computer Security Applications Conference 1990, pp. 232-243 Differential Power Analysis, Cryptography Research, Inc., http://www.cryptography.com/dpa/ The Complete, Unofficial TEMPEST Information Page, http://www.eskimo.com/~joelm/tempest.html