Information Security of Embedded Systems 10.2.2010: Logics and Proof Methods, Wrap-Up Prof. Dr....
-
Upload
beverley-griffin -
Category
Documents
-
view
212 -
download
0
Transcript of 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
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 3
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
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 4
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
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 5
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?
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 6
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
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 7
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
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 8
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
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 9
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
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 10
Example: a Payment Card Policy (1)
• P3: Allow up to 3 purchases per day
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 11
Example: a Payment Card Policy (2)
• PE: Guarantee payment to emergency services twice
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 12
Example: a Payment Card Policy (3)
• Pcc: A cash card: spend no more than $500 total
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 13
Example: a Payment Card Policy (4)
• PN: No alcohol can be purchased
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 14
Example: a Payment Card Policy (5)
• Pt: Prevent purchases of prescription drugs which conflict with the anti-depressant Tofranil
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 15
Complete Model
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 16
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
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 17
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
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 18
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!
17.2.2010Embedded Security © Prof. Dr. H. Schlingloff 2010 19
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 !!!