CHANCES AND RISKS FOR SECURITY IN MULTICORE PROCESSORS

CHANCES AND RISKS FOR SECURITY IN MULTICORE PROCESSORS Prof. Dr.-Ing. Georg Sigl Institute for Security in Information Technology Technical University Munich sigl@tum.de Fraunhofer Research Institution for Applied and Integrated Security AISEC georg.sigl@aisec.fraunhofer.de

CONTENTS Security in embedded systems Attacks overview Multicore Chances Risks Future secure embedded systems

MAIN SECURITY CHALLENGES IN FUTURE (MULTICORE-) EMBEDDED SYSTEMS Security for 10 and more (30) years. Secure autonomous interaction of heterogenous machines (M2M). Protection against manipulation and misuse. Fulfilling security requirements while keeping real time requirements. Consider resource limitations. Managing increasing complexity in embedded systems. Protection of intellectual property (hardware and software) in embedded systems against counterfeiting. Support of adaptation of cyber physical systems through securely adaptable embedded systems.

What is the solution? Secure Element : Security module with small attack surface (low complexity) Designed to resist hardware and software attacks Which could be certified Secure Elements tasks: Integrity check / Remote Attestation Authentication / Access control Key storage / Secure memory Examples: Automotive, Smart Grid, Mobile Phones

Secure element in cars AISEC integrates a Secure Element in a care in the BMBF Project SEIS (Sicherheit in eingebetteten IP-basierten Systemen) Task: Access control between internal and external IP based network Internet Gateway OEM Server Secure Element

Secure Element im Smart Meter The BSI Protection Profile requests a Secure Element in the gateway of a Smart Meter. Secure Element Source: Protection Profile für das Gateway eines Smart Metering Systems; http://www.bsi.bund.de

Secure Elements in mobile phones 3 Secure Elements SIM Security chip Secure SD card

Attacks

Classification of Hardware Attacks Side-channel Probing & Forcing Fault

Example: PIN check with 4 digits function pin_verification( digit_entered[1:4] ) if (digit_entered [1]!= PIN_digit[1] ) return(false); if (digit_entered [2]!= PIN_digit[2] ) return(false); if (digit_entered [3]!= PIN_digit[3] ) return(false); if (digit_entered [4]!= PIN_digit[4] ) return(false); return(true)

Fault Attack function pin_verification( digit_entered[1:4] ) if (digit_entered [1]!= PIN_digit[1] ) return(false); if (digit_entered [2]!= PIN_digit[2] ) return(false); if (digit_entered [3]!= PIN_digit[3] ) return(false); if (digit_entered [4]!= PIN_digit[4] ) return(false); return(true)

Fault Attack with Laser Station

Side-channel attack function pin_verification( digit_entered[1:4] ) if (digit_entered [1]!= PIN_digit[1] ) return(false); if (digit_entered [2]!= PIN_digit[2] ) return(false); if (digit_entered [3]!= PIN_digit[3] ) return(false); if (digit_entered [4]!= PIN_digit[4] ) return(false); return(true) I I I I t t t t

Measurement Station for Differential Power Analysis

Electromagnetic Analysis

Classes of Software Attacks Injection of malicious code (e.g. through buffer overflow) Broken authentication / session management (access control) Insufficient separation of different applications (side channel e.g. cache) Security misconfiguration (e.g. no SW update) Insecure cryptographic storage Insufficient transport layer protection (confidentiality, denial of service) Derived from OWASP Top 10: https://www.owasp.org/index.php/category:owasp_top_ten_projec

Opportunities through Multicore

Opportunities: Redundancy Attack tolerance e.g. Fault injections with laser Inject jump to bypass security checks Modify register content Modify alarm signals Multi-core: Redundant cores to tolerate fault-attacks: e.g. SLE 78 redundant computation, majority voting, monitoring 18

Opportunities: Randomization Attack tolerance e.g. side-channel attacks Timing (execution time of cryptographic operations) and power (power consumption) attacks to crack keys Multi-Core Increased resistance against side-channel attacks: e.g. using multi-cores for randomized execution of cryptographic algorithms

Opportunities: Separation Take advantage of multi-cores Assign security/safety critical tasks to dedicated security cores (e.g. hardened cores): secure execution environment strict access controls Distribute sensitive functions between different cores to enhance resistance against reverse engineering attacks and side channel attacks

Opportunities: Self-monitoring Separate a security core from data processing cores : Trusted OSs in monitoring system Collect data in userland OS (e.g. syscall traces) Securely analyze data to detect misbehavior Dynamic health monitoring Extend Virtual Machine Introspection to enhance malware detection on multi-cores See BMBF project HIVE.

Risks through Multicore

Risks through Software Attacks Injection of malicious code Shared Resources Integrity measurement (with TPM, e.g.) Secure boot on MC systems? Broken authentication / session management Authentication not implemented: all on same SoC!? Who manages all SW on multicore system? Insufficient separation of different applications Common caches, busses, peripherals, memories,

Risks through Software Attacks Security misconfiguration (e.g. no SW update) Could be implemented through security core Insecure cryptographic storage Memory separation? Bandwidth to access secure element? Insufficient transport layer protection Encrypted on-chip networks On-chip authentication and integrity protection

Risks through Hardware Attacks Fault attacks No difference to standard cores Side channel attacks Distributed unsecure hardware accelerators which are vulnerable to hardware attacks Cryptographic algorithms are executed on standard cores because performance permits it Probing Unsecure networks on chip Remark: Implementation of hardware security is complex! No methodology for SoC design available

Discussion: Architectures of Multicore Systems with Hardware Secure Elements Abstract: Currently PC systems as well as embedded system often contain a hardware secure element. In the PC this is the trusted platform module and in the embedded world we see smart cards (e.g. SIM) like secure elements. In the future we will get very complex Multicore systems. The security architecture of future systems is open. There are many questions, e.g.: Will there be one or many hardware trust anchors How are secure elements integrated in a Multicore system What will be the security architecture of the operating system: secure/trusted boot, virtual or real secure element No dedicated secure elements but distributed security services -

What is the right software architecture? Separation Process Virtualization / Sandboxing System Virtualization Secure Monitoring Virtual Machine Introspection for malware detection Attack tolerance Secure OS Trustworthy component Rich OS 3 rd Party Application Android including Dalvik VM L4Linux with Android patches VMM (L4 Microkernel) Multi-core (SoC)

What is the right hardware architecture? M2M SIM other System on Chip GSM ID Actuator ID Sensor Trust Core 1 OS Core 2 IO-interfaces Peripherals Core i Core n RAM Flash System on Chip Hardware Security Module

From Embedded System to Cyber Physical System Required Privacy Non repudiation Confidentiality + Access Control Authenticity + Integrity Security Services Sensor µcontroller Actuator Embedded System (ES) ES ES Bus; Serial IF ES ES Locally Connected ES Internet Cyber Physical System System Complexity