information security of embedded systems 10.2.2010: logics and proof methods, wrap-up prof. dr....

Information Security of Embedded Systems

10.2.2010: Logics and Proof Methods, Wrap-Up

Prof. Dr. Holger SchlingloffInstitut für Informatik

undFraunhofer FIRST

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

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. authentication4. authorization

7. Formal methods for security

1. protocol verification2. logics and proof

methods8. Wrap-Up


Integrated Security Design

• Systematic consideration of security goals Requirements, specifications, models, code, test

suites

• Model-based design system model refined to implementation model assertions as logical formulas automated code generation particularly well-suited for embedded systems

• Modelling formalisms UML Matlab/Simulink/Stateflow automata

http://www.mathworks.com/


Example: Security Policies

•Lit.: M. McDougall, R. Alur, C. Gunter: A Model-Based Approach to Integrating Security Policies for Embedded Deviceshttp://seclab.uiuc.edu/cgunter/dist/McDougallAG04.pdf

Security policies Programmable payment cards Policy automata, defeasible logic Model checking and code generation

http://seclab.uiuc.edu/cgunter/dist/McDougallAG04.pdf

http://seclab.uiuc.edu/cgunter/dist/McDougallAG04.pdf


Security Policies

• Goal: restrict permission to certain transactions e.g. money withdrawal only if account positive

• Stateful: result of a request may depend on previous decisions e.g. the amount withdrawn during the current day

• Various stakeholders may impose different policies e.g. employer: withdrawal only on business trips e.g. parent: withdrawal only up to certain amount

• Non-monotonic: new policy may override previous policy e.g. withdrawal always possible for “good customers”

• Problem: conflicting policies?• Problem: correct implementation of policy?


Programmable Payment Cards

• Authorization of transactionsaccording to a policy

• ROM, EEPROM on card, can be programmed (Java)

• After being issued card allows to add policies but not to remove them

• Policies provide boolean result, transaction is allowed iff approved by each of the policies


Defeasible Logic

• non-monotonic logic new axioms not necessarily increase theory efficient proof/disproval method

• -> Strict rule always (necessarily) valid (cf. modal logic!) (penguin -> ¬fly)

“penguins don’t fly”• => Defeasible rule

usually valid, but can be preempted by other information (bird => fly)

“birds can fly unless we have some reason to think otherwise”

• ~> Defeater rule block the tentative conclusions of defeasible rules (injured ~> ¬fly) will block the above rule

⊢yes, ⊬ ¬yes approval;⊬ yes disapproval;⊢yes, ⊢¬yes conflict


Policy Automata

• Given T: transactions (e.g. <price, seller>), D: votes (rules of defeasible logic)

• policy automaton A=(M, X, q0, R, δ) M: modes, X: variables, Q: states; q0: initial state R: rules; R: Q x T D δ: transitions; δ: Q x T x {yes, no} Q

• Policy model = set of policy automata automata proceed simultaneously depending on the approval outcome the “yes” or

“no” transition is traversed in case of conflict an error state is assumed


Example: a Payment Card Policy

• P3: Allow up to 3 purchases per day

• PE: Guarantee payment to emergency services twice

• Pcc: A cash card: spend no more than $500 total

• PN: No alcohol can be purchased

• Pt: Prevent purchases of prescription drugs which conflict with the anti-depressant Tofranil


Example: a Payment Card Policy (1)

• P3: Allow up to 3 purchases per day



• PE: Guarantee payment to emergency services twice



• Pcc: A cash card: spend no more than $500 total



• PN: No alcohol can be purchased



• Pt: Prevent purchases of prescription drugs which conflict with the anti-depressant Tofranil


Complete Model


Analysis of Policy Models

•The following properties can be verified reachability conflict-freeness redundancy of a policy

•Code generation is possible translation of automata into Java card applets adding of applets to a pre-configured card defeasible logic engine in runtime environment

•Tool “Polaris” graphical editor, analysis engine, code

generator


Wrap-Up: What we have learned…

• Systematics of security throughout the system’s functionality throughout the system’s design throughout the system’s operation

• Assess security goals, take measures measures must be adapted to possibilities measures may change over time

• Security for embedded needs special care processing, energy, design challenges mass-market, price, non-revocability, …

• Social processes and consequences


Further Topics

• Attacks on different levels HW tampering, modifications side channels

• Security testing verification on all levels impossible test case selection intrinsically hard

• Future: Intentious systems autonomous agents self-organizing systems

Many things to research!


Organizational Matters

•mündliche Prüfungen => Frau Heene Prüfungen bitte noch in 2010!

•Bescheinigungen etc. => Mit ausgefülltem Formular direkt bei mir

•weitere Kurse SS 2010: Grundlagen der Programmierung WS 2010/11: Modellbasierte

Entwicklung

•Schöne Semesterferien !!!

information security of embedded systems 10.2.2010: logics and proof methods, wrap-up prof. dr....

Documents