1. Information Security of Embedded Systems 6.1.2010: Design of Secure Systems Prof. Dr. Holger Schlingloff Institut für Informatik und Fraunhofer FIRST

2. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 20102 Happy New Year! Have you read today’s newspaper?  banking card problem “2010” (30M€)  Mars spaceship problem (???$) You’re in the right lecture!

3. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 20103 Structure 1. Introductory example 2. Embedded systems engineering 1.definitions and terms 2.design principles 3. Foundations of security 1.threats, attacks, measures 2.construction of safe systems 4. Design of secure systems 1.design challenges 2.safety modelling and assessment 3.cryptographic algorithms 5. Communication of embedded systems 1.remote access 2.sensor networks 6. Algorithms and measures 1.digital signatures 2.key management 3.authentification 4.authorization 7. Formal methods for security 1.protocol verification 2.logics and proof methods

4. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 20104 Recap –Threats, Attacks, Principles Threats  virus, worms, trojan horses  mobile code, activeX Communication attacks  link layer  network layer  transport layer  application layer General construction principles  fail-safe defaults, complete mediation, need-to-know, open design, economy of mechanisms System construction phases  PID controller

5. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 20105 Design Challenges Tamper resistance, security even under physical attack Low processing capacities, form factor “Processing Gap” High energy costs, battery life “Battery Gap” Rapidly evolving architectures Engineering vs. information processing Ravi, Raghunathan, Kocher, Hattangady: Security in Embedded Systems:Design Challenges; ACM Trans. ECS3,3,2004

6. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 20106 Gaps “Processing gap”  cost for security calculations increase quicker than the available processing power “Battery gap”  battery capacity increase and energy consumption decrease slower than security cost inflation “Flexibility”  embedded systems difficult to upgrade, new attacks arise continually “Tampering”  reengineering methods and tools becoming readily available “Assurance gap”  functional complexity increase quicker than verification technology “Cost”  balance between security requirements and implementation costs

7. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 20107 Security Functions Kocher, Lee, McGraw, Raghunathan, Ravi: Security as a New Dimension in Embedded System Design; DAC 2004 data confidentiality data integrity authentication

8. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 20108 Security Concepts Encryption  symmetric and asymmetric ciphers, public key methods Access control policies Secure hashing Security protocols  e.g., SSL, IPSec, VPNs Digital Signatures  certificates  biometrical data Digital Rights Management  watermarking, steganography Cryptographic hardware accelerators Embedded processor support for cryptography Multicore for security Open design Redundancy Timing analysis Electromagnetic resistance Capacitors

9. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 20109 Embedded Security Pyramid Knezevic, Rozic and Verbauwhede: Design Methods for Embedded Security

10. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201010 Another Model of Mobile Security Areas of consideration “Abstract to concrete”  property areas  target areas  application areas Sun, Howie, Koivisto, and Sauvola: A Hierarchical FrameworkModel of Mobile Security

11. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201011 Property Theory Layer Objectives  confidentiality  integrity  availability Attacks  intrusion orientation  sources of attack  attacked targets  attack methods Mechanisms  protection, cryptography, authentication, monitoring…

12. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201012 Limited Targets Layer Networking Computers, OS Multimedia

13. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201013 Classified Applications Layer Samples  more? Discussion of the two models?

14. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201014 Safety Modelling and Assessment “Common Criteria for Information Technology Security Evaluation” Specification, implementation and evaluation of security requirements  Results to be comprehensible, comparable and traceable  comparable to IEC61508 for safety assessment International standard (ISO/IEC 1540, 1998-2009)  Replaces predecessors - TCSEC (Trusted Computer Eval. Criteria, 1980) - ITSEC (Information Technology Security Evaluation Criteria, 1991)  Mutual acknowledgement between countries  V3.1 released July 2009 Certification for systems by accredited institutions  in Germany: BSI Sources available at http://www.commoncriteriaportal.org/

15. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201015 Certified Products Network and Network related Devices and Systems Operating systems Access Control Devices and Systems Biometric Systems and Devices Boundary Protection Devices and Systems ICs, Smart Cards and Smart Card related Devices and Systems Key Management Systems Data Protection systems, Databases Detection Devices and Systems Products for Digital Signatures Trusted Computing

16. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201016 Structure Part 1: general model  glossary, foundations of evaluation, protection profiles, security targets Part 2: functional requirements  catalogue of recommendations  connections between threats, goals and requirements Part 3: assurance requirements  guideline on evaluation methodology and process  protection profile and security target evaluation

17. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201017 Key concepts Target Of Evaluation (TOE)  system to be evaluated Protection Profile (PP)  security requirements for a class of security devices Security Target (ST)  security properties of the TOE; may refer to one or more PPs Security Functional Requirements (SFRs)  individual security functions provided by a product Security Assurance Requirements (SARs)  measures taken during development Evaluation Assurance Level (EAL)  numerical rating of an evaluation; EAL 1-7

18. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201018 Functional Security Classes functionality classes  FAU: security audit  FCO: communication  FCS: cryptographic support  FDP: user data protection  FIA: identification and authentication  FMT: security management  FPR: privacy  FPT: protection of the security functions  FTA: TOE access  FTP: trusted path/channels

19. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201019 Components of Security Classes e.g. FCS: cryptographic support key generation key distribution key access key destruction specified algorithm

20. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201020 Evaluation assurance levels in CC (EAL1) functionally tested  “provides meaningful increase in assurance over an unevaluated IT product or system”  development according to normal engineering standards (EAL2) structurally tested  requires “developer testing, vulnerability analysis, and independent testing”  formulation of security goals, threats, informal architecture plan, test documentation (EAL3) methodically tested and checked  more complete testing, tamper resistance during development  informal implementation plan, test result evaluation

21. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201021 Evaluation assurance levels in CC (EAL4) methodically designed, tested, and reviewed  requires design descriptions, partial implementation check, informal model; correlation between design and implementation (EAL5) semiformally designed and tested  semiformal design descriptions, structured architecture, covert channel analysis; formal security model (EAL6) semiformally verified design and tested  vulnerability analysis, structured implementation, environment controls  explanation instead of description (EAL7) formally verified design and tested  formal representations and correspondences, comprehensive testing  mathematical proofs of algorithms

22. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201022 Evaluation methods Analysis and checking of processes and procedures Checking that processes and procedures are being applied Analysis of the correspondence between design representations Analysis of design representations against the requirements Verification of proofs Analysis of the guidance documents Analysis of tests and test results Functional and penetration testing

23. 6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 201023 Critique + Certification possible for many TOEs +- Generality of approach + Evaluation maintenance - Evaluation usually complex and costly (~10 6 $) - Lenghthy process; certified products outdated - No direct increase in security by assessment - Not for open source and agile development