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

Information Security of Embedded Systems

6.1.2010: Design of Secure Systems

Prof. Dr. Holger SchlingloffInstitut für Informatik

undFraunhofer FIRST

6.1.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 2

Happy New Year!

•Have you read today’s newspaper? banking card problem “2010” (30M€) Mars spaceship problem (???$)

•You’re in the right lecture!


Structure

1. Introductory example2.Embedded systems

engineering1. definitions and terms2. design principles

3.Foundations of security1. threats, attacks, measures2. construction of safe

systems

4.Design of secure systems1. design challenges2. safety modelling and

assessment3. cryptographic algorithms

5. Communication of embedded systems

1. remote access2. sensor networks

6. Algorithms and measures

1. digital signatures2. key management3. authentification4. authorization

7. Formal methods for security

1. protocol verification2. logics and proof

methods


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


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


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


Security Functions

Kocher, Lee, McGraw, Raghunathan, Ravi: Security as a New Dimension in Embedded System Design; DAC 2004

• data confidentiality• data integrity• authentication


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


Embedded Security Pyramid

Knezevic, Rozic and Verbauwhede: Design Methods for Embedded Security


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


Property Theory Layer

• Objectives confidentiality integrity availability

• Attacks intrusion orientation sources of attack attacked targets attack methods

• Mechanisms protection, cryptography, authentication,

monitoring…


Limited Targets Layer

•Networking

•Computers, OS

•Multimedia


Classified Applications Layer

•Samples more?

•Discussion of the two models?


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/


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


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


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


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


Components of Security Classes

•e.g. FCS: cryptographic support

key generation

key distribution

key access

key destruction

specified algorithm


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


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


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


Critique

+ Certification possible for many TOEs+- Generality of approach+ Evaluation maintenance

- Evaluation usually complex and costly (~106$)

- Lenghthy process; certified products outdated- No direct increase in security by assessment - Not for open source and agile development

Documents

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