Embed Size (px)
Citation preview
Security and Validation in Modern SoC Designs
Sandip Ray Strategic CAD Labs
Intel Corporation [email protected]
Cooperation, Conflicts, and Compromises
Acknowledgements • Sean Baartmans • Debra Bernstein • Jeremy Casas • Kai Cong • Victor DelaGarza • Jason Fung • Iwan Grau • Raghudeep Kannavara • Sava Krstic • Li Lei • Rebekah Leslie-Hurd • Dhinesh Manoharan • David Ott • Jim Schwartz • Mark Tuttle • Jin Yang
• Abhishek Basak • Swarup Bhunia • Bo Chen • Christopher Havlicek • Sharad Malik • Prabhat Mishra • Fei Xie
How can we ensure security and trustworthiness of computing systems?
Changing Computing Landscape…
General-purpose systems Complex, optimized architecture Versatility and programmability Diverse use-case scenarios Customized design
Unique use-case constraints Tight HW/SW integration
Embedded systems mbedded sy
Customized design Unique use-case constraints Tight HW/SW integration
Complex, optimized architecture Versatility and programmability Diverse use-case scenarios
How can we ensure security and trustworthiness of highly complex modern computing systems?
…Computing In Everyone’s “Hands”…
Too many opportunities to attack Users less savvy/caring of system internals and vulnerabilities
Potential Attacks on a Smartphone Attacks on Privacy via malicious apps and in-app Ad libraries
SMS
Calender
Pictures
Location
Contacts
E-Mails
Music Browser Attacks
Premium-Rate Services
Hardware Attacks
Exploit Mobile Cloud Apps
SIM and SD Card, NFC
E l it
Sensor Malware
…Built On Aggressive Schedules
Product Timeline
Planning Production
Development Exploration
3-4 years < 1 year 333--444 yyyeeeaaarrrsss<< 111 year
…Built On Aggressive Schedules
Product Timeline
Planning Production
Development Exploration
3-4 years < 1 year 333--444 yyyeeeaaarrrsss<< 111 year
How can we ensure security and trustworthiness of highly complex computing systems operating in an environment of billions of complex, error-prone, possibly malicious communicating devices, built under extremely aggressive time-to-market requirements?
…Built On Aggressive Schedules
Product Timeline
Planning Production
Development Exploration
3-4 years < 1 year aaarrrsss
How can we ensure security and trustworthiness of highly complex computing systems operating in an environment of billions of complex, error-prone, possibly malicious communicating devices, built under extremely aggressive time-to-market requirements?
• (Interoperabiliy) Ensure that the system still functions • (Validation) Ensure that the resilience works • (Architecture) Build In Resilience to Attacks
vvvvvvvvvvve
eeeeeeeeeeeeaaa3 4
PPPPlllaaaannnnnnnniiiinnnng DevEEEExxxxpppplllloooorrrraaaatttiiiioooonnnn
333333333333-444444444444 yyyyyyyyyyeeeeeeeeee<<<<< 111111111 yyyyyyyyyeeeeeeeeaaaaarrrrrrrrrHardware/software co-design Computer Architecture Formal Methods Analytics EDA
Different Faces of Security
Device Security • NFC and RFID • Hardware primitives such
as PUFs
System Security • HW/FW/SW Interactions • System-level Policies • Design and development
of security architectures
Cloud Security
• Mobile cloud • Cloud clients and
infrastructures
• Security in Systems and Platforms • Assets and Policies • Validation Planning and Threat Analysis • Validation Activities
− Fuzzing − Penetration Testing − Formal Verification
• Security and Validation Trade-offs • Conclusion
Agenda
Platform Security
Platform Security Assurance
Review the overall platform for attack opportunities which undermine security objectives in ways not covered by traditional approaches
• All software, firmware, and hardware • Including third party • Potentially including services • Don’t forget the board
• All reasonable attacker starting points • Software, physical access
• All reasonable attacker motivations • Data theft, jaiolbreaking, DRM bypass,
remote access, DoS, ….
Platform Security Assurance
Review the overall platform for attack opportunities which undermine security objectives in ways not covered by traditional approaches
• All software, firmware, and hardware • Including third party • Potentially including services • Don’t forget the board
Platform Security Assurance
Review the overall platform for attack opportunities which undermine security objectives in ways not covered by traditional approaches
• Feature security objectives • Architectural security objectives • OS and App security objectives • User’s security sxpectation
Platform Security Assurance
Review the overall platform for attack opportunities which undermine security objectives in ways not covered by traditional approaches
• Minimize duplication of efforts • Find gaps in current approaches • Third party interactions • ….
Assets and Policies
The “CIA” Pillars Confidentiality
Confidentiality
Integrity
− Read access control of sensitive data − Authorization and authentication are essential
− Write access control of sensitive data − Authorization and authentication are essential
− Fault tolerance, Robustness, Handle bad inputs, DoS − Fail safe, handle exceptions safely and securely
What’s in Security Policy?
− Keys (Developer/OEM) − Premium content − End user information − (Firmware) Execution
flows − Debug modes − …. − ….
− Confidentiality − Integrity − Anti-replay − Privacy Aspects − …. − ….
Policy
Assets Protection Requirement
• Multiple owners over lifetime of the parts • Multiple IPs that do not trust each other
Access to Assets
Manufacturer Service Provider OEM
Security Engine
Graphics Engine
Secure Element
Fuse Controller
Memory Controller
DRAM
Keys
SoC
Content Key Storage E-wallet
Control Reg Sensor
Data
Stakeholders
Stakeholders provision Assets such as Keys, E-wallet which reside in SoC building blocks such as Fuses, Secure Element etc.
For every access to assets and building blocks holding and managing them, determine: Who is accessing the asset? What actions are requested? When access is requested?
As Assets flow through the various SoC building blocks during boot, additional assets are created at runtime
Example Requirement: Fuses
In-Field Programmable Fuses are used by manufacturer and OEMs
Read/write to manufacturer fuses is governed by manufacture requirements
Read/write to OEM fuses is governed by OEM policy
Don’t allow manufacturer to read/write when not in fab
Don’t allow anybody to read/write content keys
Policy Enforcement
Who What When
Intel R/W Manuf.
Policy Enforcer
Manuf. IFP OEM IFP
Lifecycle
Manufacturing
Who What When
Intel R/W Prod.
Policy Enforcer
Manuf. IFP OEM IFP
Lifecycle
Production
Who What When
OEM R/W Prod.
Policy Enforcer
Manuf. IFP OEM IFP
Lifecycle
Production
More Complexity: Fabrics
High-speed, coherent Fabric
CPU
DRAM
IP IP
Low-speed Fabric
IP
GFX
Communication Fabric
Router Router
More Complexity: Fabrics
High-speed, coherent Fabric
CPU
DRAM
IP IP
Low-speed Fabric
IP
GFX
Router Router
− Message immutability − Redirection prevention − Masquerade prevention − Non-observability
• BARs used to get to the destination • Transactions over IOSF primary subject to
redirection by host OS • Cannot trust OS controlled BARs • Alternate routing mechanism necessary for
secure communication
Validation Planning
Science and Art of Security Validation
Art Science
Functional validation of
features providing security assurance
White Box Expert Hacking Negative Testing
Validation of Deterministic
Security Requirements
Well-defined / Low Complexity Exploratory / High Complexity
Functional validation of
features providing
Validation of Deterministic
S i
Example: Crypto engine encrypts and decrypts data correctly on all modes
p yp
securityyy aassuuraancee
Example: Crypto
Crypto, secure boot, patching, etc.
S itSecurityy RRRRReeeeeeqqqqqqqquuuuuuiiiiiirrrrreeeeeemmmmmeeeeeennnnntttttsssss
Access control restrictions, address translation, etc. Bugs are likely overlooked during normal usage Bugs are likely overlookedduuurrriiiinnnggggg nnnooorrrmmmaaallll uuusssaaagggggeee
Example: Calls to DMA access to DMA-protected memory range through DMA address translation regs. must be aborted
s
NNNNNNNeeeeeggggggggaaaaatttttiiiiivvvvveeeee TTTTTeeeeessssstttttiiiiinnnnngggggggg
s,
Look beyond what is specified, see if security objectives can be subverted or are underspecified dbe subverted or are
ddd be subverted or are undersppecified
Example: Are there other paths to protected DMA memory in addition to DMA address translation regs? How to activate them?
e
n
hite Box Expppert HHHHHHHaaaaaaccccckkkkkkkkiiiiiiinnnnggggggggg
WhhWh
er
n
Goal-oriented attempts by expert hackers at breaking security objectives (often at HW/FW/SW divide or chip boundary)
Three Easy Steps to Validation
− Identify the security objectives −Model the security threats −Validate objectives against threats
Adversaries in SoC Security Asset owners − Manufacturer, OEM, End user
−Adversary Capabilities − Unprivileged software adversary − System software adversary − Software side-channel/covert-channel adversary − Simple hardware adversary − Skilled hardware adversary − Hardware reverse-engineer adversary
Adversaries − Manufacturer, OEM, End user
Modeling Threats Define/ Review Security
Objectives
Identify/ Review System Assets
Define Protections and Mitigations
Update Specs and Iterate
Define/ Review trust Levels & Entry points
Enumerate and Rank threats Product Specs
Section 1
Section N
.
.
.
Security Section(s)
Security Objective 1
Security
Objective 2
Threats
Attack Points
Test Strategy
Etc
Mitigation Strategy and requirements
Etc
Product Specs
Prior Issues
Usage Models
Example: Code Injection Threats
Boot Code ROM
Embedded Core
Cache SRAM
DRAM
Secondary Storage (HDD, Flash, etc)
SR-1: Protect memory range from access by untrusted DMA engines.
SR-2: Prevent direct access to internal memory from untrusted code.
SR-3:Write-protect non-volatile memory region.
RAM
Security Objective: Prevent Code Injection in storage and runtime memory
Assets: Cache SRAM, DRAM, Secondary storage
Threats: • Untrusted device access to DRAM
through DMA • Write to internal cache SRAM • Corrupt secondary storage
Threat Analysis: Complexity − Model perspective
− Entry point identification’
− Risk Assessment
− Attacker-centric, starts with attacker motivation and ability − Asset-centric, starts with assets − System-centric, starts with system execution flow
How many entry points are there: − Debug feature? Crypto keys? Display ports?
− Damage Potential − Reproducibility − Exploitabiliy − Affected Systems − Discoverability
Validation Activities
Fuzzing
A method for discovering faults in design by providing unexpected inputs and monitoring for exceptions
Fuzzer Vectors
• Long strings • Symbols • Bit flipping • Large integers
Interface Observed behavior
• System hang • Crash • …
Fuzzing
A method for discovering faults in design by providing unexpected inputs and monitoring for exceptions
Fuzzer Vectors
• Long strings • Symbols • Bit flipping • Large integers
Interface Observed behavior
• System hang • Crash • …
• Buffer overflows • Integer overflows • Access violations • Unhandled exceptions
• DoS • Race/Timing errors • Memory leaks • …
Fuzzing Approaches Dumb/Mutated
Smart/Generated
• Random inputs or randomly mutated valid input, throw any and all at it
• Easy and fast to apply
• Generated anomalies based on comprehensive knowledge of target
• Significant up front investment • Greater coverage
Penetration Testing A penetration test is an attack on a computer system with the intention to find security weakness, potentially gaining access to it, its functionality, and data
• Enumerate the attack surface • Exploit/perform the attack • Analyze results against objectives
Penetration Testing Flavors − Documentation Review − Known vulnerability − Missing patches − Out-of-date software − Known Misconfigurations
− Related Misconfigurations − Related Vulnerabilities − Tool Smorgasbord
− Component Analysis − Vulnerability Classes − Platform Horizontal/Integration Testing − Vulnerability Research
Formal Verification
Heavy-weight Full verification of critical modules, e.g., cryptographic core
Light-weight Using static analysis methods to exercise different system paths and expose vulnerabilities
Use of mathematical and symbolic methods to formally prove a desired property of the system
Formal Verification: Case Study
Is the firmware that is finally loaded always the authenticated firmware?
No
• A counterexample requires 3 concurrently running flows with the right interleaving
• Difficult to achieve through penetration testing or fuzzing
Validation and Security Trade-offs
The Big Conflict Testability and debug requirements often collide with security requirements
Post-silicon validation and HVM test require extensive observability and control of internal signals
Security needs conflict with observability, and drives for elimination of debug controls
Need a systematic approach to create a design in which observability does not risk the confidentiality and integrity of assets
Current State of Trade-off Secrets locked up, debug allowed
Secrets sandboxed, debug allowed
???
Debug allowed with user-supplied keys
Functional mode, some debug conditionally allowed
Security-Debug Trade-off Challenges
• HVM Challenges
• Validation Challenges
• Reusability Considerations
• Control logic Issues
• Observability Considerations
• Variability Challenges
Designing and validating security of complex modern embedded systems is a critical problem Addressing the problem requires strong collaboration among several areas in Computer Science and Engineering We have made some progress, but our research has only scratched the surface of this vast domain The future road in this area is uncertain, exciting, and crucial to our well-being
Conclusion ““It’s good to do something that scares you” - --- Ellen DeGeneres
