formal security modeling - von oheimb
Post on 15-Feb-2022
4 Views
Preview:
TRANSCRIPT
Formal Security Modeling
Dr. David von Oheimb
David.von.Oheimb@siemens.com
ddvo.net
Information & Communications Security
Siemens Corporate Technology
Munich, Germany
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 3
Contents
• Introduction
• Access Control
-– example: medical database
• Automata for modeling reactive systems
-– example: Infineon SLE66
• Information Flow
-– example: Infineon SLE66
• Cryptoprotocol Analysis
-– example: Needham-Schroeder Protocol
• Evaluation & Certification
-– example: Infineon SLE88
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 4
Material
• Slides: http://www.tcs.ifi.lmu.de/lehre/SS05/Sicherheit/
• Books
� Claudia Eckert: IT-Sicherheit. Oldenbourg, 3rd ed. 2004.
� Matt Bishop: Introduction to Computer Security. Add.-Wes., 2004.
� Dieter Gollmann: Computer Security. Wiley, 2000.
� US Department of Defense. DoD Trusted Computer System
Evaluation Criteria (The Orange Book), DOD 5200.28.STD, 1985.
• Articles
� Heiko Mantel, Werner Stephan, Markus Ullmann, and Roland Vogt:
Leitfaden fur die Erstellung und Prufung formaler Sicherheits-modelle im Rahmen von ITSEC und Common Criteria.Bundesamt fur Sicherheit in der Informationstechnick (BSI), 2002
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 5
Papers
• D. Elliot Bell and Leonard J. La Padula: Secure Computer Systems:Unified Exposition and Multics Interpretation. MITRE Technical
Report. 2997, 1976.
• VR. S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman; Role-BasedAccess Control Models. IEEE Computer 29(2): 38-47, 1996
• David von Oheimb and Volkmar Lotz: Formal Security Analysis withInteracting State Machines. ESORICS 2002.
• David von Oheimb, Volkmar Lotz and Georg Walter: Analyzing SLE88 memory management security using Interacting State Machines.International Journal of Information Security, 2005.
• John Rushby: Noninterference, Transitivity, and Channel-ControlSecurity Policies. SRI International Technical Report CS-92-02, 1992.
• David von Oheimb: Information flow control revisited:Noninfluence = Noninterference + Nonleakage. ESORICS 2004.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 6
Contents
• Introduction
• Access Control
• Information Flow
• Cryptoprotocol Analysis
• Evaluation & Certification
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 7
Outline
+ What is Information Security?
• Goals, Threats, and Mechanisms
• Security Policies
• Security Models
• Security Modeling and
Software Engineering
• Conclusions on Security
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 8
Information Security
• IT/Computer security deals with the prevention, or at least detection,
of unauthorized actions or possession by users of a computer system.
� Authorization is central to definition.
� Sensible only relative to a security policy,
stating who (or what) may perform which actions.
• Information security is even more general. It deals with information
independent of computer systems.
Note that information is more general than data. Data represents or
conveys information. But information may also be revealed without
revealing data, e.g., by statistical summaries.
• Constitutes a basic right: protection of self (posessions, ...).
• Complements safety: prevent damage through errors or malfunction
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 9
Security according to Common Criteria
torisk
to reduce wish to minimize
give rise to
wish to abuse and/or may damage
that increase
may be aware of
Owners
Attackers
vulnerabilities
measures
to
threats
value
assets
leading to
reduced bythat may be
that may possess
impose
that exploit
• Classification depicts fundamental concepts and interrelationships.
• Policy (here implicit) defines authorized actions on assets,
i.e., what constitutes legal use (or abuse/damage, respectively).Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 10
Example: email
reduced by
wish
to
that increase
that
assets
Owners
threats
Threat agents
give rise to
countermeasures
vulnerabilities
risk
minimize
exploitleading to
wish to abuse and/or may damage
to
value
impose
to reduce
that may be
to
that may possess
Assets: Mail
Threats:
• Who sent the mail?
• Has it been received?
• Was the mail read by others during transport?
• Was the mail modified during transport?
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 11
Example: e-votingreduced by
wish
to
that increase
that
assets
Owners
threats
Threat agents
give rise to
countermeasures
vulnerabilities
risk
minimize
exploitleading to
wish to abuse and/or may damage
to
value
impose
to reduce
that may be
to
that may possess
Assets: Data, e.g., individual votes, voter identity, results, etc.
Threats: (sample)
• How will the system ensure that only registered voters vote?
• How will it ensure that each voter can only vote once?
• How does the system ensure that votes are not later changed and
are correctly tabulated?
• How are votes kept private and identities secret?
• System availability? Functional correctness?Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 12
E-voting — Swiss requirements
Elektronische Wahl- und Abstimmungssysteme und die elektronische Sammlungvon Unterschriften mussen unter allen Umstanden sicher funktionieren und vormoglichen Gefahren und Einwirkungen von außen geschutzt sein. Sie mussendabei ebenso viel Sicherheit bieten wie die gegenwartig geltenden Systeme.Das bedeutet allerdings nicht hundretprozentige Sicherheit. Auch das geltendeAbstimmungssystem kennt Schwachstellen.
??
??
Requirements in practice are difficult to formulate precisely.This is part of the challenge in designing secure systems.Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 13
Outline
• What is Information Security?
+ Goals, Threats, and Mechanisms
• Security Policies
• Security Models
• Security Modeling and
Software Engineering
• Conclusions on Security
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 14
Security Goals
• Goals: CIA
Confidentiality: No unauthorized disclosure/leakage of information
Integrity: No unauthorized modification of information
Availability: No unauthorized impairment of functionality
Note that CIA all require some form of authorization,
which consists of some form of authenticationand access control.
• Other goals
Privacy: User data is only exposed in permitted ways.
Nonrepudiation: One cannot deny responsibility for actions.
Also called accountabilityApplication specific requirements: E.g.,
e-voting must suitably combine above!
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 15
Threats
Interception
Modification
Confidentiality
Fabrication
InterruptionAvailability
access to informationUnauthorized party gains
Generation of additional
Unauthorized tamperingof data or services
unavailable or unusableService or data becomes
data or activitiesIntegrity
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 16
Security Mechanisms
Let’s consider how different mechanisms can be used to achieve
goals in the face of threats, and what some of the challenges are.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 17
Confidentiality/Privacy
Example Email is not a letter
but rather a post card!
Threat Everyone can read it along the way!
Mechanism Network security, encryption, and access control
Challenges Key and policy management
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 18
Data integrity
Example Email (or forms, records, ...)
Threat Unallowed modification/falsification
Mechanism Digital signatures and/or access control
Challenges PKI and policy management
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 19
Availability
Example Communication with a server
Threats Denial of Service, break-ins, ...
Mechanism Fire-walls, virus-scanners,
backups, redundant hardware, secure
operating systems, etc.
Challenges Difficult to cover all threats
(and still have a usable system)
Also difficult to test/verify, because
availability is a liveness property:
“something good eventually happens”,
while all others are safety properties:
“something bad never happens”
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 20
Authentication: who is who?
Example
Threats Misuse of identity
Mechanisms
Credentials of requester: personal characteristics (biometric),
what one has (smartcard), or what one knows (password).
Processes, Data : cryptographic protocols, digital signatures, etc.
Challenges authentication hardware/mechanisms,
protocol design/analysis, PKIs
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 21
Access Control (AC): who has what permission?
Example Access to data, processes, networks, ...
Threats Unauthorized access of resources
Mechanisms Declarative and programmatic control mechanisms
SecurityAdmin
User
AuthorizationDatabase
Objects
AUTHENTICATION ACCESS CONTROL
AUDITING
ReferenceMonitor
Challenges Policy design, integration, and maintenance
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 22
AC: Authorization and Auditing
SecurityAdmin
User
AuthorizationDatabase
Objects
AUTHENTICATION ACCESS CONTROL
AUDITING
ReferenceMonitor
Authentication establishes/verifies identity of requester.
Authorization decides whether legitimate (authenticated) requester
is allowed to perform the requested action.
Auditing gathers data to discover violations or diagnose their cause.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 23
A few words about auditing
SecurityAdmin
User
AuthorizationDatabase
Objects
AUTHENTICATION ACCESS CONTROL
AUDITING
ReferenceMonitor
• Two components:
� collection and organization of audit data,
� analysis of data to discover or diagnose security violations.
• Intrusion detection:
� Passive: offline analysis to detect possible intrusions or violation.
� Active: real time analysis to take immediate protective response.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 24
A few words about auditing (cont.)
• Questions:
� How to determine what has to be audited?
� What to look for in audit log data?
� How to determine violation automatically?
• Possible solutions:
� Anomaly detection: the exploitation of the vulnerabilities involves
abnormal use of the system.
� Misuse detection: based on rules specifying sequences of events or
observable properties of the system, symptomatic of violations.
• Auditing data needs protection from modification by an intruder.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 25
Summary: Goals, Threats, and Mechanisms
• Standard breakdown. Important for analyzing system security relative
to a policy.
• Designing adequate mechanisms is challenging.
• One must take a holistic approach to security engineering.
� Security must be co-designed with the system, not added on.
� One must be cognizant of the tradeoffs and costs involved.
• There are many open questions, both at the level of mechanisms and
the design/integration process.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 26
Outline
• What is Information Security?
• Goals, Threats, and Mechanisms
+ Security Policies
• Security Models
• Security Modeling and Software Engineering
• Conclusions on Security
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 27
An example: university computing
• IT security policy:
A student has full access to information that he or she created.
Students have no access to other students’ information unless
explicitly given. Students may access and execute a pre-defined
selection of files and/or applications. ...
• Security policy describes access restrictions.
• Issues
� How do we formalize such a policy?
� What mechanisms would we use to enforce it?
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 28
Two more examples
• E-Banking
A bank customer may list his account balances and recent transactions. He maytransfer funds from his accounts provided his total overdraws are under 10,000.Transfers resulting in larger overdraws must be approved by his account manager. ...
Above policy describes restrictions where objects here include both
data and processes.
• Privacy policies A clerk may only have access to personal data if this access isnecessary to perform his/her current task, and only if the clerk is authorized toperform this task.In addition, the purpose of the task must correspond to the purposes for which thepersonal data was obtained or consent must be given by the data owners.
Combines conditions with obligations on how data will be used.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 29
Security Policies
• A security policy defines what is allowed.
It defines those executions (actions, data flow, etc.)
of a system that are acceptable,
or complementarily, those that are not acceptable.
� Typically defines a relationship between subjects and objects.
� It is analogous to a set of laws.
� Typically defined as high-level requirements.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 30
CIA as security policiesLet S be a set of subjects and I some information (or a resource).
Confidentiality: I has the property of confidentiality with respect to S
if only members of S can obtain information about I.
Integrity: I has the property of integrity with respect to S
if all members of S can trust I.
Members of S can trust information I if the conveyance and storage
of I did not change the information (data integrity). If I contains
information about the origin of something, or identity of someone,
then this information must be correct and unchanged (origin integrity
or authentication).
Availability: I has the property of availability with respect to S
if all members of S can access or use I.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 31
Outline
• What is Information Security?
• Goals, Threats, and Mechanisms
• Security Policies
+ Security Models
• Security Modeling and Software Engineering
• Conclusions on Security
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 32
Security Models
• A security model is a formal description
of a system and a policy (or of a family of policies).
N.B.: model is overloaded in literature.
E.g., formal policy, security mechanisms, semantic models, ...
• How are (un)acceptable executions specified?
Usually in terms of system state or sequences of states (traces).
• Models usually focus on specific characteristics of policies.
• We will consider
� Access Control models
� Information Flow models
� Cryptoprotocol models
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 33
What are Formal Methods?
• A language is formal if it has a well-defined syntax and semantics.
Examples: Predicate logic, automata, λ−calculus, process algebra,
. . .
• A model is formal if it is specified with a formal language.
Example:
∀x. bird(x)→ flies(x) bird(tweety)
• A proof is formal if it is done using a deductive system
(i.e., a set of precise rules governing each proof step).
Examples: Tableau calculus, axiomatic calculus, term rewriting, . . .
• A formal proof is machine-assisted if
it is performed, or at least checked, by an IT system.
Examples: OFMC (model checker), Isabelle (theorem prover)Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 34
Access Control models
• Discretionary vs. mandatory AC models.
• Various types of models:
� Models can capture policies
for confidentiality (Bell-LaPadula)
or for integrity (Biba, Clark-Wilson).
� Some models apply to static policies (Bell-LaPadula),
others consider dynamic changes of access rights (Chinese Wall).
� Security models can be informal (Clark-Wilson),
semi-formal, or formal (Bell-LaPadula).
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 35
Information Flow models
• Identify domains holding information
• Specify allowed flow between domains
• Check the observations that can
be made about state and/or actions
• Consider also indirect and partial flow
• Classical model: Noninterference
(Goguen & Meseguer)
• Many variants: Non-deducability, Restrictiveness, Nonleakage, ...
downgr.
public
secret
confidential
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 36
Cryptoprotocol models
• Describe message traffic between processes or principals
Yes.
Is it you, Alice?
• Take cryptographic operations as perfect primitives
• Are specified with by domain-specific languages (e.g. HLPSL)
• Describe secrecy, authentication, . . . goals
• Are typically verified automatically using model-checkers
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 37
Protection state
• A state of a system is the collection of current values of all memory
locations, storage, registers, and other components.
• The substate addressing security is the system protection state.
• Examples of protection states
File system: part of system state determining who is reading/writing
files, access control information, etc.
Network: e.g., packet header information (identifying protocols) and
packet locations, internal firewall states, etc.
Program: e.g., part of run-time image corresponding to
program counter, call stack, memory management tables, etc.
• Abstraction: system execution described
as transitions between protection states
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 38
Protection state and security policy• Let P be the system state space and Q ⊆ P be the states
in which system is authorized to reside in.
� A state s ∈ Q is called authorized (or secure),
� any s ∈ P \Q is called unauthorized (or nonsecure).
• A security policy characterizes Q.
Hence a security policy partitions the states of the system into
authorized (or secure) states, and unauthorized (or nonsecure) states.
• A security mechanism prevents a system from entering P \Q.
A secure system is a system that starts in an authorized state and
cannot enter an unauthorized state.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 39
Example 1: Kerberos Kerberos
Authentication server (KAS)
Ticketgrantingserver (TGS)
• Provides Single Sign-On mechanism in a distributed setting.
• Partitions authentication, authorization, and access control.
Security policy: expresses which users can access what servers in a
realm (or cross-realm).
The policy is determined by the system administrator who registers
users/servers in the database.
Security mechanism: Kerberos and kerberized application front-ends.
Protection state: Kerberos server state (e.g., policy tables),
state of protocol runs, client state, server state.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 40
Example 2: security policy for proprietary dataSecurity policy for company X
All information on product Y is confidential: it may only be read or modified
by a subgroup Z and the system administrators.
Mechanism implications
• All printouts must be securely stored or shredded.
• All computer copies must be protected (AC, cryptography, ...)
• As company X stores its backup tapes in a vault in the town bank, X
must ensure that only authorized employees have access to these tapes.
Hence the bank’s control on access to the vault and the procedures used to
transport tapes to/from the bank are considered as security mechanisms.
The security mechanisms are not only technical controls, but also procedural
or operational controls.
Protection stateNot just the IT state, but also existence and location of physical goods.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 41
Outline
• What is Information Security?
• Goals, Threats, and Mechanisms
• Security Policies
• Security Models
+ Security Modeling and Software Engineering
• Conclusions on Security
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 42
Security as a Software Engineering Problem
Situation: security loopholes in IT systems will be actively exploited
— in this sense even worse than safety problems!
Goal: achieve absence of attacks by absence of vulnerabilities
— and convince contractors/customers/users of this!
Problem: IT systems are very complex, security flaws hard to find.
Remedy: address security in all development phases.
Reviews supported by formal security modeling/analysis.
During ...
• requirements analysis: helps understanding the security issues
• design, documentation: helps improving the quality of specifications
• implementation: acts as correctness reference for
testing/verification
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 43
Why are Formal Security Models so helpful?
A formal security model is an abstract formal description of a system
(and its environment) that focuses on the relevant security issues.M BA
M
{ N , A }K
{ N , A }K
{ N , N , }K
A
A B
M
A B{ N , N , }KB
A B
A
A
Interpretation
Abstraction
Its advantages/goals are:
• improves understanding of security by abstraction:
simplification and concentration on the essentials
• prevents ambiguities, incompleteness, and inconsistencies
and thus enhances quality of specifications
• provides basis for systematic testing or even formal verification
and thus validates correctness of implementations
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 44
Modeling considerations
Abstraction Level: should be ...
• high enough to achieve clarity
• low enough not to loose important detail
refinement allows for both high-level and detailed description
Formality Level: should be adequate:
• the more formal, the more precise,
• but requires deeper mastering of formal methods
Choice of Formalism: dependent on ...
• application domain, modeler’s experience, tool availability, ...
• formalism should be simple, expressive, flexible, mature
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 45
Outline
• What is Information Security?
• Goals, Threats, and Mechanisms
• Security Policies
• Security Models
• Security Modeling and
Software Engineering
+ Conclusions on Security
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 46
Conclusions
• Security is an enabling technology.
• Security is a cross-section topic.
Formal Methods
Networks Cryptography Operating Systems
Software EngineeringDistributed Computing
Legal Context Business Processes
IT Security
• Security is difficult.
... and therein lies the challenge, excitement, and reward!
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 47
Contents
• Introduction
• Access Control
• Information Flow
• Cryptoprotocol Analysis
• Evaluation & Certification
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 48
Outline
+ Access Control (AC)
• Discretionary Access Control (DAC)
• Mandatory Access Control (MAC)
• Access Control Matrix Model
• Role-Based Access Control (RBAC)
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 49
Access control
Many security policies (and mechanisms) focus on access control.
Access Control:Protection of system resources against unauthorized access;
a process by which use of system resources is regulated
according to a security policy that determines authorized access.
certain subjects (entities, e.g. users, programs, processes)
have permissions (e.g. rwx)on objects (e.g. data, programs, devices)
according to AC policies.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 50
AC Policies vs. AC Mechanisms
• Policy: specifies (un-)authorized accesses of a system
and how access decisions are determined.
� Discretionary AC.
� Mandatory AC.
� Role-based AC.
• Mechanism (structure): implements or enforces a policy.
� Access matrix.
� AC list (ACL).
� Capability list.
This distinction allows for abstraction and independence.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 51
Access control — typical mechanisms
• System knows who the user is, i.e. authentication is done.
• Access requests pass through a gatekeeper (“reference monitor”).
SecurityAdmin
User
AuthorizationDatabase
Objects
AUTHENTICATION ACCESS CONTROL
AUDITING
ReferenceMonitor
OS must be designed that way: MMU, file system, firewall, . . .
OS-level AC provides basis for application-specific mechanisms.
• We will now look at several different access control models.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 52
Outline
• Access Control (AC)
+ Discretionary Access Control (DAC)
• Mandatory Access Control (MAC)
• Access Control Matrix Model
• Role-Based Access Control (RBAC)
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 53
Discretionary Access Control (DAC)
• Premise: users are owners of resources and are responsible for
controling their access.
• The owner of information or a resource is able to change its
permission at his or her discretion. Owners can usually also transfer
ownership of information to other users.
• Flexible, but open to mistakes, negligence, or abuse.
� Requires that all system users understand and respect security policy
and understand AC mechanisms.
� Abuse, e.g. Trojan horses may that trick users into transferring rights.
• Dissemination of information is not controlled:
a user who is able to read data can pass it to other users not
authorized to read it without cognizance of the owner.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 54
Types of DAC policies
• Closed DAC policies: authorization must be explicitly specified,
since the default decision of reference monitor is denial.
• Open DAC policies: specify denials instead of permissions
(default decision is access).
• Combination of positive and negative authorizations possible
(but quite complex).
Example: Deny in Windows XP
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 55
A DAC example: Unix
• Unix provides a mechanism suitable for a restricted class of DAC policies.
� Controls access per object using permission scheme owner/group/other.� Permission bits assigned to objects by their owners.
-rw-r--r-- 1 luca softech 56643 Dec 8 17:19 file1.tex drwxrwxrwt 26root root 4096 Dec 9 22:27 /tmp/ -rwsr-xr-x 1 root shadow 80036 Oct3 11:08 /usr/bin/passwd*
• Not all policies can be directly mapped onto this mechanism.
How would we express that a patient can read his medical records at a hospital?Who owns the records? In which group is the patient?
• Supports limited delegation of rights using suid (“set user identification”) [or sgid].
� Executor takes on owner’s user [or group] identity during execution.� Example: normal users “upgraded” to root privileges to change their passwords in
the password file.� Open to abuse and the cause of many security holes.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 56
Outline
• Access Control (AC)
• Discretionary Access Control (DAC)
+ Mandatory Access Control (MAC)
• Access Control Matrix Model
• Role-Based Access Control (RBAC)
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 57
Mandatory Access Control (MAC)
• System wide access restrictions to objects.
Mandatory because subjects may not transfer their access rights.
• AC decisions controlled by comparing
security labels indicating sensitivity/criticality of objects, with
formal authorization, i.e. security clearances, of subjects.
• Example from military: users and objects assigned a clearance level
like confidential, secret, top secret, etc. Users can only read [write]
objects of equal or lower [higher] levels.
• More rigid than DAC, but also more secure.
• Concrete examples (like Bell-LaPadula) later.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 58
MAC: Linear Ordering
Confidential
Top secret
Secret
Unclassified
Write up
Read down
Two principles are required to hold for confidentiality:
• Read down: a subject’s clearance must dominate (i.e. ≥)
the security level of the object being read.
• Write up: a subject’s clearance must be dominated by (i.e. ≤)
the security level of the object being written.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 59
MAC: Linear Ordering (cont.)
Confidential
Top secret
Secret
Unclassified
Write up
Read down
• Problems:
� It allows to send email “up”, but is often restricted only to same
level (i.e. =) to avoid “blind overwriting”.
� It does not allow a subject to write “lower” data; to that end a
subject should be enabled to dynamically decrease its level.
• Can be applied similarly for integrity: read up and write down:
Protected
Unrestricted
Read up
Write down
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 60
MAC: Ordering generalized
Def: a partial ordering (L,v) on a set L is a binary relation on L
(i.e. a subset of L× L) that is reflexive, antisymmetric, and transitive.
Example: Hasse diagram of company secrets
Strategic
Product1 Product2 Product3
Techn2
Public
Techn1
Questions:
• Given 2 objects at different security levels, what is the minimal level
a subject must have to be allowed to read both objects?
• Given 2 subjects at different security levels, what is the maximal level
an object can have so that it still can be read by both subjects?
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 61
MAC: The Lattice of Security Levels
Def: a lattice (L,v) is a partial ordering (L,v) on a set (of security
levels) L, so that for every two elements a, b ∈ L there exists
a least upper bound u ∈ L and a greatest lower bound l ∈ L, i.e.
a v u and b v u and ∀u′ ∈ L. (a v u′ ∧ b v u′)→ u v u′
l v a and l v b and ∀l′ ∈ L. (l′ v a ∧ l′ v b)→ l′ v l
We write lub({a, b}) or atb for u
and glb({a, b}) or aub for l.
Examples:
• the linear ordering on the naturals: (N,≤)
• the subset ordering on powersets: (℘(S),⊆)
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 62
Example (from DoD’s Orange Book)• A set H of classifications with a hierarchical (linear) ordering ≤.
• A set C of categories, e.g. project names, company divisions, etc.
• A security label is a pair (h, c) with h ∈ H and c ⊆ C.
• Partial order of labels: (h1, c1) v (h2, c2) iff h1 ≤ h2 and c1 ⊆ c2.
For hierarchical levels
public and private, and
categories PERSONNEL
and ENGINEERING, we
have the lattice:
Note that
public,{PERSONNEL} 6vprivate,{ENGINEERING}.
private, {PERSONNEL, ENGINEERING}
private, {PERSONNEL} private, {ENGINEERING}
public, {PERSONNEL, ENGINEERING}
private, {}
public, {PERSONNEL}
public, {}
public, {ENGINEERING}
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 63
Outline
• Access Control (AC)
• Discretionary Access Control (DAC)
• Mandatory Access Control (MAC)
+ Access Control Matrix Model
• Role-Based Access Control (RBAC)
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 64
Access Control Matrix Model
• Simple framework for describing a protection system by describing the
permissions of subjects on objects.
Subjects: users, processes, agents, groups, ...
Objects: files, memory banks, other processes, ...
Permissions (or rights): read, write, execute, print, ...
• Policy is a finite relation P ⊆ Subjects× Objects× Permissions
Objects
Permissions
Subjects
OwnRW
OwnRW
RW
InquiryCredit
InquiryDebit
InquiryCredit
InquiryDebit
File 1 File 2 File 3 File 4 Account 1 Account 2
OwnRX
WXAlice
Bob
Charlie R
RR W
given as a matrix.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 65
AC Matrix Model — formal definitions (I)
• A state (or: configuration) is a triple X = (S, O, M):
S ⊆ Subjects: Set of subjects.
O ⊆ Objects: Set of objects.
M : Subjects×Objects→ ℘(Permissions): a matrix defining the
protection state, i.e. the permissions for each (s, o) ∈ S ×O
where M(s, o) := {p ∈ Permissions | (s, o, p) ∈ P}
• State transitions described by commands (members of a set Com) like
� enter permission p into M(s, o)� create subject s
� destroy object o
These transform one state into another by changing its parts.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 66
AC Matrix Model — formal definitions (II)
• Write X ;c X ′ to denote a state transition associated with c,
where c ∈ Com is a command.
• A starting state X0 = (S0, O0,M0) and the transition relation ;
determine a state-transition system. baa
c
• So a model describes a set of (possible) system traces,
namely (finite) sequences of transitions
X0 ;c1 X1 ;c2 X2 . . . ;cn Xn
where all Xi ∈ State and all ci ∈ Com.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 67
Access matrix — policy exampleOwn
RW
OwnRW
RW
Alice
Bob
CharlieOwn
RX
WX
R
RR W
File 1 File 2 File 3 File 4
Policy: A subject has read access to a file only if the permission R was
initially present or has been explicitly granted by the file’s owner.
Formalization:For any s1, s2 ∈ Subjects and o1 ∈ Objects,
confer read(s2, s1, o1) ∈ Com is a command whose effect on the state is
(S, O, M) ;confer read(s2,s1,o1) (S, O, M ′) where
(∀s, o. M ′(s, o) = (if (s, o) = (s1, o1) then M(s, o)∪{R} else M(s, o))).
Let X0 ;c1 X1 . . . ;cn Xn be a system trace. State Xn is authorized iff
∀s′, o′. R ∈Mn(s′, o′)→ (R ∈M0(s′, o′) ∨(∃k < n, s. Xk ;confer read(s,s′,o′) Xk+1 ∧ Own ∈Mk(s, o′))).
Security Objective: the system is secure, i.e. all reachable states are
authorized, i.e. for all traces X0 ;c1 X1 . . . ;cn Xn the Xn is authorized.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 68
Access matrix — policy example (cont.)Own
RW
OwnRW
RW
Alice
Bob
CharlieOwn
RX
WX
R
RR W
File 1 File 2 File 3 File 4
Solution: For each transition that gives new read access to an object, access controlchecks that this has been done by the owner of the object using confer read. Formally:
Let X = (S, O, M) and X ′ = (S′, O′,M ′) be two states and c a command.The transition X ;c X ′ is locally acceptable iff (R 6∈M(s′, o′) ∧ R ∈M ′(s′, o′))→(∃s. c = confer read(s, s′, o′) ∧ Own ∈M(s, o′)).
Theorem: If access control makes sure that only locally acceptable transitions takeplace, then all reachable states are authorized, i.e. the system is secure. Formally:
For any trace X0 ;c1 X1 . . . ;cn Xn, if Xi ;ci+1Xi+1 is locally acceptable for all i,
then Xn is authorized for all n.
Proof: Assume that all transitions Xi ;ci+1Xi+1 are locally acceptable.
Show by induction on n that Xn is authorized.
Base case: X0 is trivially authorized.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 69
Access matrix — policy example (cont.)Own
RW
OwnRW
RW
Alice
Bob
CharlieOwn
RX
WX
R
RR W
File 1 File 2 File 3 File 4
Induction step: Take any trace X0 ;c1 X1 . . . ;cn+1 Xn+1. We can assume
that Xn is authorized and have to show that Xn+1 is authorized.
Choosing any s′ and o′ such that R ∈Mn+1(s′, o′),it remains to show R ∈M0(s′, o′) ∨ (∃k < n + 1. Q(k))where Q(k) := (∃s. Xk ;confer read(s,s′,o′) Xk+1 ∧ Own ∈Mk(s, o′)).We consider two cases.
1. R ∈Mn(s′, o′), i.e. R did not change.
From the ind. hypothesis, we conclude R ∈M0(s′, o′) ∨ (∃k < n. Q(k)).Now R ∈M0(s′, o′) ∨ (∃k < n + 1. Q(k)) follows immediately.
2. R 6∈Mn(s′, o′), i.e. R is newly set in Mn+1(s′, o′).Since the transition Xn ;cn+1 Xn+1 is locally acceptable, we can infer
∃s. cn+1 = confer read(s, s′, o′) ∧ Own ∈Mn(s, o′)).Thus we have Q(n) and therefore R ∈M0(s′, o′) ∨ (∃k < n + 1. Q(k)).
2Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 70
Access matrix — policy example with Isabelle
Isabelle: generic interactive theorem proving system
HOL: higher-order logic, mixture of predicate logic and λ-calculus
ProofGeneral: XEmacs mode for Isabelle etc., used in live demo now
theory AC_matrix = Main:
typedecl Subject
typedecl Object
datatype Permission = Own | R | other_Permissions
types Protection_State = "Subject × Object ⇒ Permission set"
State = "Subject set × Object set × Protection_State"
datatype Com = confer_read "Subject × Subject × Object"
| other_Coms
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 71
Access matrix — policy example with Isabelle: tracesFor simplicity, only one trace, of unbounded lengthconsts X :: "nat ⇒ State"
C :: "nat ⇒ Com" — 0-th command unusedsyntax"X_" :: "nat ⇒ State" ("X " )
"S_" :: "nat ⇒ Subject" ("S " )
"O_" :: "nat ⇒ Object" ("O " )
"M_" :: "nat ⇒ Protection_State" ("M " )
"C_" :: "nat ⇒ Com" ("C " )
translations"Xn" "X n"
"Sn" "fst Xn"
"On" "fst (snd Xn)"
"Mn" "snd (snd Xn)"
"Cn" "C n"
consts transition :: "State ⇒ Com ⇒ State ⇒ bool" ("(_ ;_. _)")
constdefs is_trace :: "bool"
"is_trace ≡ ∀ n. Xn ;C (n+1). X (n+1)"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 72
Access matrix — policy example with Isabelle: misc
axioms transition_confer_read: — unused"(S,O_,M) ;confer_read(s2,s1,o1).
(S,O_,(λ(s’,o’). if (s’,o’) = (s1,o1) then M(s’,o’) ∪ {R} else M(s’,o’)))"
constdefs authorized :: "nat ⇒ bool"
"authorized n ≡ ∀ s’ o’.
R ∈ Mn (s’,o’) −→R ∈ M0 (s’,o’) ∨ (∃ k<n. ∃ s. C (k+1) = confer_read(s,s’,o’) ∧ Own ∈ Mk (s,o’))"
constdefs locally_acceptable :: "nat ⇒ bool"
"locally_acceptable i ≡ ∀ s’ o’.
(R /∈ M i (s’,o’) ∧ R ∈ M (i+1) (s’,o’)) −→(∃ s. C (i+1) = confer_read(s,s’,o’) ∧ Own ∈ M i (s,o’))"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 73
Access matrix — policy example: Isabelle proof script
“Classcial” tactic style, “proof assembly language”
theorem system_safe: " [[is_trace; ∀ i. locally_acceptable i ]] =⇒ ∀ n. authorized n"
apply (rule allI)
apply (rule nat.induct)
apply (unfold authorized_def)
apply (fast)
apply (rule allI, rule allI, rule impI)
apply (case_tac "R ∈ Mna (s’, o’)")
apply (drule spec, drule spec, erule (1) impE, erule disjE)
apply (erule disjI1)
apply (rule disjI2)
apply (erule exE, erule conjE)
apply (rule_tac x = k in exI)
apply (blast intro: less_SucI)
apply (simp add: locally_acceptable_def)
apply (drule spec, drule spec, drule spec, erule impE, erule (1) conjI)
apply (rule disjI2)
apply (rule_tac x = na in exI)
apply (blast)
done
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 74
Access matrix — policy example: Isabelle ISAR proof
Mostly automatic prooftheorem system_safe: " [[is_trace; ∀ i. locally_acceptable i ]] =⇒ authorized n"
apply (rule nat.induct)
apply (simp_all add: authorized_def locally_acceptable_def)
apply (blast intro: less_SucI)+
done
Intelligible Semi-Automatic Reasoningtheorem system_safe: " [[is_trace; ∀ i. locally_acceptable i ]] =⇒ ∀ n. authorized n"
prooffix n
assume local_accept: "∀ i. locally_acceptable i"
show "authorized n"
proof (induct n, simp_all only: Suc_plus1)
show "authorized 0" by (unfold authorized_def, fast)
nextfix n
assume ind_hyp: "authorized n"
show "authorized (n+1)"
proof (unfold authorized_def, rule, rule, rule)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 75
fix s’ o’
assume assumpt: "R ∈ M (n+1) (s’, o’)"
let ?Q = "λk. ∃ s. C (k+1) = confer_read (s, s’, o’) ∧ Own ∈ Mk (s, o’)"
show "R ∈ M0 (s’, o’) ∨ (∃ k<n+1. ?Q(k))"
proof cases
assume "R ∈ Mn (s’, o’)"
with ind_hyp have "R ∈ M0 (s’, o’) ∨ (∃ k<n. ?Q(k))"
by (unfold authorized_def, fast)
then show ?thesis by (simp, blast intro: less_SucI)
nextassume "R /∈ Mn (s’, o’)"
with local_accept assumpt
have "∃ s. C (n+1) = confer_read (s, s’, o’) ∧ Own ∈ Mn (s, o’)"
by (simp add: locally_acceptable_def)
hence "?Q(n)" .thus "R ∈ M0 (s’, o’) ∨ (∃ k<n+1. ?Q(k))" by (simp, fast)
qedqed
qedqed
end
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 76
Access matrix: data structures
• Matrices define access rights.
• Different possible realizations as mechanism.
Access Matrix AC List (ACL) Capabilities List
OwnRW
OwnRW
RW
Alice
Bob
CharlieOwn
RX
WX
R
RR W
File 1 File 2 File 3 File 4
OwnRW
Alice
WX
OwnR
Charlie
X
OwnRW
R
W
R
R
RW
File 2
File 3
File 4
File 1 Alice Bob Charlie
Bob Charlie
Bob
Bob
R
File 2
File 1
Bob
R
Charlie
Alice File 3
R
File 2
OwnRW X
W
File 1 File 3
Own
WR W R
File 4
W
File 1
OwnRX
File 4
Represent as 2-dimensional objects or set of 1-dimensional objects.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 77
Access-control (authorization) list• ACL: use lists to express view of each object o:
ith entry in the list gives the name of a subject si
and the rights ri in M(si, o) of the access-matrix.
• Standard example: AC for files.
User ID Rights
fileF
ACL for FFile Directory
FAlice Own, RWBob RWCharlie RJohn R
Owner has the sole authority to grant, revoke or
decrease access rights to F to other users.
Exception in UNIX: superuser (“root”) always
has full access and can change all access rights.
OwnRW
Alice
WX
OwnR
Charlie
X
OwnRW
R
W
R
R
RW
File 2
File 3
File 4
File 1 Alice Bob Charlie
Bob Charlie
Bob
Bob
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 78
Capability list
OwnRX
RW
File 1Charlie File 2 File 4
R
• Subject view of AC matrix.
• Less common than ACLs.
� Not so compatible with object oriented view of the world.
� Difficult to get an overview of who has permissions on an object.
� Difficult to revoke a capability for a set of users. E.g., chmod o-rwx *
• Application in distributed setting (e.g., mobile agent, Kerberos).
Users are endowed with credentials (e.g., from a credential server)
that they present to network objects.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 79
Outline
• Access Control (AC)
• Discretionary Access Control (DAC)
• Mandatory Access Control (MAC)
• Access Control Matrix Model
+ Role-Based Access Control (RBAC)
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 80
Why RBAC?
• How do we formalize a policy when there are 103 − 106 subjects and
objects? AC matrices do not scale!
• Overcome using standard tricks: abstraction and hierarchy.
Abstraction: Many subjects (or objects) have identical attributes, and
policy is based on these attributes.
Hierarchy: Often functional/organizational hierarchies that determine
access rights.
• Approach to RBAC: decompose subject/object relationship by
introducing a set of roles. Then assign subjects to roles and
permissions to objects based on role. I.e.,
(s, o, p) ∈ P iff s has role r and r has permission p on object o.
• This idea can be generalized by introducing a hierarchy on roles.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 81
Role-Based Access Control (RBAC)
• Rights are associated with roles, and users aremade members of appropriate roles.
⇒ Simpler management of rights:
� Access decisions based on roles that users haveas part of an organization (e.g. hospital).
� Roles can have overlapping responsibilities andrights.
� Roles can be updated without updating therights of every user on individual basis.
� Enterprise-specific security policies.
• Closely related to concept of user groups:a role brings together
� a set of users on one side (as in groups) and� a set of rights.
person
research
statistics
doctor
day nurse night nurse
head nurse
nurse
medical administration
senior physician
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 82
Role-Based Access Control (RBAC) (cont.)
• Role hierarchies simplify policy expression.
• Example:
� A member of role Senior has also all permissionsdefined by Doctor.
� A Senior may delegate a task to a Doctor.� A member of roles Doctor or Patient can only
access those resources allowed under his role(s).
• Needed by enforcement mechanism:
� Rules for role assignment/authorization,and for permission assignment.
� Also: rules for delegation.
Object 1
Object 2
Object 3
Object 4
Object 5
Object 6
User 4
User 5
User 6
User 7
P,W
R
R
R
P
Doctor
R
Senior
Patient
User 1
User 2
User 3
member_of
R,P
R,W
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 83
RBAC formalization: overview
RBAC0 : plain
RBAC1 : with role hierarchy
RBAC2 : with constraints
RBAC3 : with both
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 84
RBAC formalization: RBAC0 and RBAC1
RBAC0 : plain
users: U
roles: R
permissions: P
user assignment: UA ⊆ U ×R
permission assignment: PA ⊆ R× P
sessions: AR ⊆ UA (active roles, note the restriction!)
access: can exec = AR ◦ PA ⊆ U × P ,
i.e. (u, p) ∈ can exec = ∃r. (u, r) ∈ AR ∧ (r, p) ∈ PA
RBAC1 : with role hierarchy
role hierarchy: RH ⊆ R×R, antisymmetric
sessions: AR ⊆ UA ◦ RH∗ (redefined active roles)
where X∗ = I ∪X ∪X ◦X ∪ ... is the reflexive-transitive closure
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 85
RBAC formalization: RBAC2
RBAC2 : with constraints, for instance:
static separation of duty: SSD ⊆ R×R
example: (treasurer, auditor) ∈ SD
constraint: UA−1 ◦ UA ⊆ SSD ∪ SSD−1, i.e.
((u, r) ∈ UA ∧ (u, r′) ∈ UA) −→ ((r, r′) /∈ SSD ∧ (r′, r) /∈ SSD)where Z−1 = {(y, x). (x, y) ∈ Z} is inversion,
Z = {(x, y). (x, y) /∈ Z} is complementation
dynamic separation of duty: DSD ⊆ R×R
example: (customer, customer consultant) ∈ DSD
constraint: AR−1 ◦AR ⊆ DSD ∪DSD−1
cardinality constraints: e.g. |{u. (u, branch manager) ∈ UA}| ≤ 1
prerequisite permissions: e.g.
((clerk, r) ∈ RH ∧ (r, write) ∈ PA) −→ (r, read) ∈ PA
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 86
RBAC example: complex information system
Privileges:roles ⊆ user× rolesubroles ⊆ role× roleprivs ⊆ role× privilege
user role privilege
subroles
roles privs
(u, p) ∈ roles ◦ subroles∗ ◦ privs
Permissions:groups ⊆ user× groupsubgroups ⊆ group× groupgperms ⊆ group× permissionuperms ⊆ user× permission
user group
subgroups
groupspermission
entry
gperms
uperms
(u, p) ∈ (groups ◦ subgroups∗ ◦ gperms(e)) ∪ uperms(e)Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 87
Automata
+ Input/Output Automata (IOAs)
• AutoFocus Automata
• Interacting State Machines (ISMs)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 88
Input/Output Automata (IOAs)
• each reactive system component modeled as an automaton
• state machine with actions
• transitions may be nondeterministic
• input actions cannot be blocked
• other actions under control of automaton
• automata can be composed, forming new automata
• communication via synchronized actions
• strong metatheory: refinement, compositionality, . . .
T a s r nIn Out
State
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 89
IOAs: action signatures
Interface between an automaton and its environment:
action signature S, consisting of disjoint sets
in(S): input actions
out(S): output actions
int(S): internal actions
Derived notions:
acts(S) = in(S) ∪ out(S) ∪ int(S): all actions
ext(S) = in(S) ∪ out(S): external actions
local(S) = out(S) ∪ int(S): locally-controlled actions
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 90
IOAs: automata
An I/O automaton A consists of
sig(A): action signature
states(A): set of states
start(A) ⊆ states(A): initial states (at least one)
steps(A) ⊆ states(A)× acts(A)× states(A): transition relation
input enabled: ∀σ. ∀a ∈ in(A). ∃σ′. (σ, a, σ′) ∈ steps(A)
part(A) ⊆ ℘(local(A)): countable partitioning
(used for expressing fairness, which is not an issue here)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 91
IOAs: coffee machine CM
in(S1) = {PUSH1, PUSH2}: buttons received
out(S1) = {COFFEE, ESPRESSO, DOPPIO}
int(S1) = {LOOSE}
sig(CM) = S1
states(CM) = N: variable ’button-pushed’
start(A) = {0}: initially, no button pushed
steps(A) = {(x, PUSH1, 1), (x, PUSH2, 2), (x, LOOSE, 0),(1, COFFEE, 0), (2, ESPRESSO, 0), (2, DOPPIO, 0)| x ∈ states(CM)}
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 92
IOAs: user USER
in(S2) = {COFFEE, ESPRESSO, DOPPIO}
out(S2) = {PUSH1, PUSH2}: buttons pushed
int(S2) = ∅
sig(USER) = S2
states(USER) = B× B: variables ’waiting’, ’doppio’
start(A) = {(F, F )}: not waiting and no doppio received
steps(A) = {((F, T ), PUSH1, (T , T )), ((F, F ), PUSH2, (T , F )),((w, d), COFFEE, (F , d)), ((w, d), ESPRESSO, (F , d)),((w, d), DOPPIO, (F , T )) | w, d ∈ B}
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 93
IOAs: execution
execution fragment of A: a finite sequence σ0, a1, σ1, . . . , an, σn
or an infinite sequence σ0, a1, σ1, . . . of states and actions of A
such that ∀i. (σi, ai+1, σi+1) ∈ step(A)
execs(A): execution fragments beginning with some σ0 ∈ start(A)
finexecs(A) ⊆ execs(A): finite executions of A
reachable(A): the final states σn of all finite executions of A
sched(α): the subsequence of actions in execution fragment α
(fin)scheds(A): schedules of all (finite) executions of A
beh(α): the subsequence of external actions in execution fragment α
(fin)behs(A): behaviors of all (finite) executions of A
Note: traces ((fin)execs, (fin)scheds, and (fin)beh) are prefix-closed.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 94
IOAs: coffee machine executions
execution fragment of CM :
α = [1, COFFEE, 0, PUSH2, 2, LOOSE, 0, PUSH1, 1]
execs(CM) = {[0, PUSH2, 2], [0, PUSH1, α, (PUSH1, 1)∗], . . . }
finexecs(CM) = {[0], [0, PUSH2, 2], [0, PUSH1, α], . . . }
reachable(CM) = {0, 1, 2}
sched(α) = [COFFEE, PUSH2, LOOSE,PUSH1]
(fin)scheds(CM) =
{[], [PUSH2], [LOOSE, PUSH1, COFFEE], . . . }
beh(α) = [COFFEE, PUSH2, PUSH1]
behs(CM) = {[], [PUSH2], [PUSH1, COFFEE], . . . }Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 95
IOAs: composition of signatures
A countable collection {Si}i∈I of action signatures
is strongly compatible iff
• out(Si) ∩ out(Sj) = ∅ for all i 6= j ∈ I
• int(Si) ∩ acts(Sj) = ∅ for all i 6= j ∈ I
• no action is contained in infinitely many acts(Si) for all i ∈ I
The composition Πi∈ISi of a countable collection of strongly
compatible action signatures {Si}i∈I is an action signature S with
in(S) = ∪i∈I in(Si) − ∪i∈I out(Si)out(S) = ∪i∈I out(Si) − ∅int(S) = ∪i∈I int(Si) ... ...
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 96
IOAs: composition of automata
The composition Πi∈IAi of a countable collection of
strongly compatible automata {Ai}i∈I is an automata A with
sig(A) = Πi∈Isig(Ai)states(A) = Πi∈Istates(Ai)start(A) = Πi∈Istart(Ai)steps(A) = {(σ, a, σ′) | if a ∈ acts(Ai) then
(σ[i], a, σ′[i]) ∈ steps(Ai) else σ[i] = σ′[i], i ∈ I}part(A) = ∪i∈I part(Ai)
A is input-enabled since all Ai are.
... ...
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 97
IOAs: coffee session
Compose CM and USER as CS = CM × USER.
sig(CM) and sig(USER) are strongly compatible because
• out(CM) ∩ out(USER) = ∅• int(CM) ∩ acts(USER) = ∅ and int(USER) ∩ acts(CM) = ∅• no action is contained in infinitely many {acts(CM), acts(USER)}
The composition CS = CM × USER has the components
sig(CS) = sig(CM)× sig(USER) having the components
in(sig(CS)) = EA− EA = ∅out(sig(CS)) = EA where
EA = {PUSH1, PUSH2, COFFEE,ESPRESSO,DOPPIO}int(sig(CS)) = {LOOSE}
states(CS) = N× B× Bstart(CS) = (0, F, F ), steps(CS) = . . .
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 98
IOAs: execution and composition
The projection α|Ai of an execution fragment α = σ0, a1, σ1, . . .
of a composition Πi∈IAi is the sequence obtained from α by
• deleting those aj, σj for which aj /∈ acts(Ai)• replacing all remaining σj by their i-th component σj[i]
Proposition: Let {Ai}i∈I be a countable collection of strongly
compatible automata and A = Πi∈IAi.
If α ∈ execs(A) then α|Ai ∈ execs(Ai) for every i ∈ I.
The same holds for finexecs(A), scheds(A), finscheds(A),behs(A), and finbehs(A).
Examples: α = [(0, F, F ), PUSH2, (2, T , F ), DOPPIO,
(0, F , T ), PUSH1, (1, T , T ), LOOSE, (0, T, T )]
α|CM =[0, PUSH2, 2, DOPPIO, 0, PUSH1, 1, LOOSE, 0]
beh(α)|USER =[PUSH2, DOPPIO, PUSH1]Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 99
IOAs: specification and refinement
A safety specification P is a prefix-closed set of action sequences.
An automaton A implements a specification P iff finbehs(A) ⊆ P.
An automaton A implements an automaton A′ with the same external
signature iff finbehs(A) ⊆ finbehs(A′).
Examples: P1 = sequences of actions from
{PUSH1, PUSH2, COFFEE,ESPRESSO,DOPPIO}where each COFFEE is immediately preceded by PUSH1.
Does CM implement P1? Yes. Coffee is given only promptly on request.
Does USER implement P1? No. He may receive coffee anytime.
CM is implemented by CM ′ which is like CM but never gives a doppio.
Frustrating to the USER:
behs(CM ′ × USER) = all prefixes of [(PUSH2, ESPRESSO)∗]
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 100
IOAs: compositionality
Let A be an automaton and P be a safety specification with actions
from Φ where Φ ∩ int(A) = ∅. A preserves P iff
∀β. βa|A ∈ finbehs(A) ∧ a ∈ out(A) ∧ β|Φ ∈ P −→ βa|Φ ∈ P.
Example: CM preserves P1 and USER preserves P1.
Theorem 1: Let {Ai}i∈I be a countable collection of strongly
compatible automata and A = Πi∈IAi such that in(A) = ∅.Let P be a safety specification over ext(A).If every Ai preserves P, then A implements P.
Example: CS implements P1.
Theorem 2: Let {Ai}i∈I and {Bi}i∈I be countable collections of
strongly compatible automata.
If Ai implements Bi for all i, then Πi∈IAi implements Πi∈IBi.
Example: CM ′ × USER implements CS.Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 101
IOAs: papers
• N. Lynch and M. Tuttle: An introduction to Input/Output Automata.
CWI Quarterly 2(3):219-246, 1989.
• S. Garland and N. Lynch: The IOA Language and Toolset:
Support for Designing, Analyzing, and Building Distributed Systems.
MIT/LCS/TR-762, 1998.
• O. Muller: A Verification Environment for I/O Automata Based on
Formalized Meta-Theory. PhD thesis, TU Munchen, 1998.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 102
Automata
• Input/Output Automata (IOAs)
+ AutoFocus Automata
• Interacting State Machines (ISMs)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 103
AutoFocus Automata
Automata with (nondeterministic) state transitions +
clock-synchronous i/o simultaneously on multiple connections
Automata may be hierarchical
OutT a s r nIn
Data StateControl State
Local State:
Functional language for types and expressions
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 104
Toolset
Graphical browser/editor with version control by
Modelchecking/testing/simulation tools by
Code generators by
• First Prize in competition at Formal Methods 1999
• Homepage: autofocus.in.tum.de
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 105
System Structure Diagrams (SSDs)
defining components with local variables, interfaces, and connections
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 106
State Transition Diagrams (STDs)
defining preconditions, input, output, and effects of transitions
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 107
Extended Event Traces (EETs)
describing the event order for exemplary executions and test cases
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 108
Automata
• Input/Output Automata (IOAs)
• AutoFocus Automata
+ Interacting State Machines (ISMs)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 109
Requirements
Expressiveness: state transitions, concurrency, asynchronous messages
; applicable to a large variety of reactive systems
Ease of modeling: systems describable directly
Simplicity: minimum of expertise and time required
Flexibility: adaptation and extension
Strength of the semantics: refinement, compositionality, . . .
Graphical capabilities: overview and intuition
Tool support: mature and freely available (including sources)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 110
Interacting State Machines (ISMs)
Automata with (nondeterministic) state transitions +
buffered i/o simultaneously on multiple connections
ISM system may depend on global state
Data State
Local State:
Input Buffers:
Out
Control State
InT a s r n
Global State
Transitions defined in executable and/or axiomatic styleFinite executions only (; no liveness properties)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 111
ISM Framework
AutoFocus:Syntactic perspective
Graphical documentation
Type and consistency checks
Isabelle/HOL:Semantic perspective
Textual documentation
Validation and correctness proofs
AutoFocus drawing −→ Quest fileConv1−→ Isabelle theory file
Within Isabelle: ism sectionsConv2−→ Standard HOL definitions
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 112
Elementary ISMsMSGs = P →M∗ family of messages M,
indexed by port names PCONF(Σ) = MSGs×Σ configuration
with local state ΣTRANS(Σ) = ℘((MSGs×Σ)× (MSGs×Σ)) transitions
ISM(Σ) = ℘(P)×℘(P)×Σ×TRANS(Σ) ISM type
a = (In(a),Out(a), σ0(a), Trans(a)) ISM value
Local State:
Input Buffers:
Out
Control State Data State
InT a s r n
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 113
Producer-Consumer Example
Two producers sending random integer values to a port named Inlet
of a consumer which sums them up in a local variable named Accu
Producer1
Producer2
Consumer
Inlet:int
Local State: int Accu = 0
P = {Inlet}M = Z
MSGs = {Inlet} → Z∗
Produceri = (∅, {Inlet}, •, {((¤, •), (¤(Inlet := 〈n〉), •))|n ∈ Z})Consumer = ({Inlet}, ∅, 0,
{((¤(Inlet := 〈n〉), a), (¤, a + n))|n, a ∈ Z})where ¤ = λp. 〈〉 and m(X := s) = λp. if p = X then s else m(p)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 114
Composite Runs
Let A = (Ai)i∈I be a family of ISMs. The set of composite runs
CRuns(A) of type ℘((CONF(Πi∈IΣi))∗) is inductively defined as
〈(¤,Πi∈I σ0(Ai))〉 ∈ CRuns(A)
j ∈ I
cs_(i .@. b, S[j :=σ]) ∈ CRuns(A)((i, σ), (o, σ′)) ∈ Trans(Aj)
cs _ (i .@. b, S[j :=σ]) _ (b .@. o, S[j :=σ′]) ∈ CRuns(A)
where .@. concatenates message families on a port by port basis:
m .@. n = λp. m(p) @ n(p), e.g.
(¤(Inlet := 〈1,−3〉)) .@. (¤(Inlet := 〈6〉)) = ¤(Inlet := 〈1,−3, 6〉)
i2 .@. b2σ1
b1 .@. o1
i3 .@. b3σ2
b2 .@. o2?
��?
��?
�����
������
�����
..................................................... ..........................................................
HHH
%%%.............................
������
��������
..................................................... ..........................................................
HHH
%%%.............................i1 .@. b1
σ0 t2 t3t1¤
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 115
Parallel composition of ISMs
Let A = (Ai)i∈I be a family of ISMs. Their parallel composition
‖i∈IAi is an ISM of type ISM(CONF(Πi∈IΣi)) is defined as
(AllIn(A)\AllOut(A), AllOut(A)\AllIn(A), (¤, S0(A)), PTrans(A))
where
• AllIn(A) =⋃
i∈I In(Ai)... ...
• AllOut(A) =⋃
i∈I Out(Ai)
• S0(A) = Πi∈I σ0(Ai) is the Cartesian product of all initial local states
• PTrans(A) of type TRANS(CONF(Πi∈IΣi)) is the parallel
composition of their transition relations, defined as . . .
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 116
Parallel transition relation
j ∈ I
((i, σ), (o, σ′)) ∈ Trans(Aj)((i|AllOut(A), (i|AllOut(A) .@. b, S[j :=σ ])),(o|AllIn(A), (b .@. o|AllIn(A), S[j :=σ′]))) ∈ PTrans(A)
where
• S[j :=σ] is the replacement of the j-th component of the tuple S by σ
• m|P denotes the restriction λp. if p ∈ P then m(p) else 〈〉of the message family m to the set of ports P
• o|AllIn(A) denotes those parts of the output o provided to any outer ISM
• o|AllIn(A) denotes the internal output to peer ISMs or direct feedback,
which is added to the current buffer contents b
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 117
Producer-Consumer Example: Composition & Run
I = {1, 2, 3}, A1 = Producer1, A2 = Producer2, A3 = Consumer
Σ = Πi∈IΣi = Z
A = ‖i∈IAi = (∅, ∅, (¤, 0), PCT ) where
PCT = {((¤, (b, a)), (¤, (b .@. ¤(Inlet := 〈n〉), a)))|n, a ∈ Z ∧ b ∈MSGs}
∪ {((¤, (¤(Inlet := 〈n〉) .@. b, a)), (¤, (b, a + n)))|n, a ∈ Z ∧ b ∈MSGs}
A possible trace is
〈(¤, 0),(¤(Inlet := 〈1〉), 0)), (¤(Inlet := 〈1,−3〉), 0)),(¤(Inlet := 〈−3〉), 1)), (¤,−2),(¤(Inlet := 〈6〉),−2)), (¤, 4)〉
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 118
ISM definition in Isabelle/HOL
ism name =ports pn typeinputs I pnsoutputs O pns
messages msg typestates [state type][control cs type [init cs expr0]][data ds type [init ds expr0] [name ds name]]
[ transitions(tr name [attrs]]: [cs expr (-> | →) cs expr’][pre (bool expr)+][in (I pn I msgs)+][out (O pn O msgs)+][post ((lvar name := expr)+ | ds expr’)] )+ ]
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 119
Producer-Consumer Example: Isabelle definition
datatype Pn = Inlet
ism Producer =
ports Pn
inputs "{}"
outputs "{Inlet}"
messages int
statesdata unit
transitionsproduce:
out Inlet "[n]"
record C_data = Accu :: int
ism Consumer =
ports Pn
inputs "{Inlet}"
outputs "{}"
messages int
statesdata C_data name "s"
transitionsconsume:
in Inlet "[n]"
post Accu := "Accu s + n"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 120
LKW Model of the Infineon SLE66
+ The SLE 66 family
• LKW Model
• Security Properties
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 121
The SLE 66 family
SLE 66: family of smart card chips by Infineon Technologies
• General-purpose microprocessor with RAM, ROM, and EEPROM:
• Encryption unit, random number generator, sensors, . . .
• No MMU, no on-chip operation system functionality
; Secure platform for customized BIOS and single application
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 122
SLE 66 Security Objectives
Applications: electronic passports, electronic payment systems, . . .
Security level: elementary, no assumptions about high-level functionality
Security objectives:protect information stored in the different memory components:
• The data stored in any of the memory components
shall be protected against unauthorized disclosure or modification.
• The security relevant functions implemented in firmware or hardware
shall be protected against unauthorized disclosure or modification.
• Hardware test routines
shall be protected against unauthorized execution.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 123
SLE 66 Security Mechanisms
Objectives achieved by a set of security enforcing functions:
• System life-cycle divided in several phases.
Entry to the phases controlled by test functions,
checking various preconditions and authorization.
• Data stored in memory encrypted by hardware means.
Several keys and key sources, including chip specific random number
• Sensors and active shields against physical tampering
• Provisions against differential power analysis (DPA)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 124
LKW Model of the Infineon SLE66
• The SLE 66 family
+ LKW Model
• Security Properties
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 125
Lotz-Kessler-Walter (LKW) Model
One of first formal models for security properties of hardware
Extrinsic value: Security certification on level ITSEC E4 / CC EAL5
Intrinsic value: Feedback for development and quality control
Abstract system model based on an ad-hoc automaton formalism
Formalization of security requirements, verification
Total effort: two months
Minor syntactical, typographical and semantical slips
Type errors, missing assumptions, incomplete proofs
⇒ ported to Isabelle/HOL + ISMs
Effort: two weeks
Added later: analysis of nonleakageFormal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 126
LKW Model: System Architecture
SLE66In:message Out:message
Local Variables: map(fn,val) valF map(dn,val) valD
In : input port receiving commands
Out : output port emitting results/reaction
valF maps function names to function code, e.g. firmware
valD maps data object names to data values, e.g. personalization data
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 127
LKW Model: State Transitions (abstracted)
P0
P1
P2ErrorR0.0
R1.1
R5.2
R0.2
R0.1
R5.2
R1.2
R5.2R0.0
R1.1
R5.2
R0.2
R0.1
R5.1R0.4
R2.2
R1.3
R1.4
R2.1R5.3
R3.2
R4.1
R4.2
R4.2R4.2
R3.1
R0.3
R5.1
R5.1
R5.2‘
R5.2‘
R5.2‘
R5.2
R1.2
R5.2
R4.2
Phase 0 : chip construction
Phase 1 : upload of Smartcard Embedded Software and personalization
Phase 2 : deployment (normal usage)
Phase Error : locked mode from which there is no escapeFormal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 128
LKW Model: Isabelle Theory
theory SLE66 = ISM_package:
• Build upon the general ISM theory
• Define various building blocks
• ISM section
• Underspecification often used for abstraction
• ; not all properties derivable from construction, but axioms needed
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 129
LKW Model: Names
typedecl fn — function nametypedecl dn — data object namedatatype on = F fn | D dn — object name
constsf_SN :: "fn" — the name of the function giving the serial number
constsFTest0 :: "fn set" — the names of test functions of phase 0FTest1 :: "fn set" — the names of test functions of phase 1FTest :: "fn set" — the names of all test functions
defsFTest_def: "FTest ≡ FTest0 ∪ FTest1"
axiomsFTest01_disjunct: "FTest0 ∩ FTest1 = {}"
f_SN_not_FTest: "f_SN /∈ FTest"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 130
constsF_Sec :: "fn set" — the names of all security-relevant functionsF_PSec :: "fn set" — the subset of F_Sec relevant for the processorF_ASec :: "fn set" — the names of _Sec relevant for applicationsF_NSec :: "fn set" — the names of all non-security-relevant functions
defsF_ASec_def: "F_ASec ≡ F_Sec - F_PSec"
F_NSec_def: "F_NSec ≡ -F_Sec"
axiomsF_PSec_is_Sec: "F_PSec ⊆ F_Sec"
FTest_is_PSec: "FTest ⊆ F_PSec"
constsD_Sec :: "dn set" — the names of all security-relevant data objectsD_PSec :: "dn set" — the subset of D_Sec relevant for the processorD_ASec :: "dn set" — the names of D_Sec relevant for applicationsD_NSec :: "dn set" — the names of all non-security-relevant data objects
defsD_ASec_def: "D_ASec ≡ D_Sec - D_PSec"
D_NSec_def: "D_NSec ≡ -D_Sec"
consts Sec :: "on set" — the names of all security-relevant objectsdefs Sec_def: "Sec ≡ {F fn |fn. fn ∈ F_Sec} ∪ {D dn |dn. dn ∈ D_Sec}"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 131
LKW Model: State (1)
Control state of SLE 66 ISM: phasedatatype ph = P0 | P1 | P2 | Error
typedecl val — data and function valuesconsts SN :: val — serial number
Date state of SLE 66 ISM: two partial functionsrecord chip_data =
valF :: "fn ⇀ val"
valD :: "dn ⇀ val"
The overall state:types SLE66_state = "ph × chip_data"
For simplification, date encryption left implicit
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 132
LKW Model: State (2)Lookup:constdefsval :: "chip_data ⇒ on ⇀ val"
"val s on ≡ case on of F fn ⇒ valF s fn | D dn ⇒ valD s dn"
Available functions:constdefsfct :: "chip_data ⇒ fn set"
"fct s ≡ dom (valF s)"
Functions results and their effect on the state:consts"output" :: "fn ⇒ chip_data ⇒ val"
"change" :: "fn ⇒ chip_data ⇒ chip_data"
— change is unused for test functions"positive" :: "val ⇒ bool" — check for positive test outcome
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 133
LKW Model: ISM definition (1)
Two port names:datatype interface = In | Out
Subjects issuing commands:typedecl sb
consts Pmf :: sb — processor manufacturer
Commands as input, values as potential output:datatype message =
Exec sb fn | Load sb fn val | Spy on — input| Val val | Ok | No — output
consts subject :: "message ⇒ sb"
primrec"subject (Exec sb fn ) = sb"
"subject (Load sb fn v) = sb"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 134
LKW Model: ISM definition (2)
ism SLE66 =
ports interface
inputs "{In}"
outputs "{Out}"
messages message
statescontrol ph init "P0"
data chip_data name "s" — The data state variable is called s.— The initial data state is left unspecified.
transitions...
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 135
LKW Model: Transitions, R0.0
R0.0 thru R0.4: function execution in initial phase 0.
• Only the processor manufacturer is allowed to invoke functions.
• The selected function must be present.
R0.0: if function belongs to FTest0 and the corresponding test succeeds,
phase 1 is entered, and functions FTest0 are disabled.
R00: P0 → P1
pre "f ∈ fct s∩FTest0", "positive (output f s)"
in In "[Exec Pmf f]"
out Out "[Ok]"
post valF := "valF sb(-FTest0)"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 136
LKW Model: R0.1, R0.2
R0.1: shortcut leaving out phase 1.If the function belongs to FTest1 and the test succeeds,
phase 2 is entered, and all test functions are disabled.
R01: P0 → P2
pre "f ∈ fct s∩FTest1", "positive (output f s)"
in In "[Exec Pmf f]"
out Out "[Ok]"
post valF := "valF sb(-FTest)"
R0.2: if test fails, the system enters the error state.
R02: P0 → Error
pre "f ∈ fct s∩FTest0", "¬positive (output f s)"
in In "[Exec Pmf f]"
out Out "[No]"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 137
LKW Model: R0.3, R0.4
R0.3: successful execution of all other function:
the function yields a value and may change the chip state
R03: P0 → P0
pre "f ∈ fct s - FTest"
in In "[Exec Pmf f]"
out Out "[Val (output f s)]"
post "change f s"
R0.4: in all remaining cases of function execution,
the chip responds with No and its state remains unchanged.
R04: P0 → P0
pre "sb 6= Pmf ∨ f /∈ fct s"
in In "[Exec sb f]"
out Out "[No]"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 138
LKW Model: R1.1-R1.4: functions in upload phase 1
R11: P1 → P2
pre "f ∈ fct s∩FTest1", "positive (output f s)"
in In "[Exec Pmf f]"
out Out "[Ok]"
post valF := "valF sb(-FTest1)"R12: P1 → Error
pre "f ∈ fct s∩FTest1", "¬positive (output f s)"
in In "[Exec Pmf f]"
out Out "[No]"
R13: P1 → P1
pre "f ∈ fct s - FTest1"
in In "[Exec Pmf f]"
out Out "[Val (output f s)]"
post "change f s"
R14: P1 → P1
pre "sb 6= Pmf ∨ f /∈ fct s"
in In "[Exec sb f]"
out Out "[No]"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 139
LKW Model: R2.1 and R2.2
R2.1 and R2.2: function execution in usage phase 2,
analogously to R0.3 and R0.4.
R21: P2 → P2
pre "f ∈ fct s"
in In "[Exec sb f]"
out Out "[Val (output f s)]"
post "change f s"
R22: P2 → P2
pre "f /∈ fct s"
in In "[Exec sb f]"
out Out "[No]"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 140
LKW Model: R3.1 and R3.2
R3.1 and R3.2: function execution in the error phase:
the only function allowed to be executed is chip identification.
R31: Error → Error
pre "f_SN ∈ fct s"
in In "[Exec sb f_SN]"
out Out "[Val SN]"
R32: Error → Error
pre "f /∈ fct s∩{f_SN}"in In "[Exec sb f]"
out Out "[No]"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 141
LKW Model: R4.1 and R4.2
Effects of uploading new functionality.
• Must be done by the processor manufacturer
• Allowed only in phase 1
• Meanwhile, also security-critical application functions are loadable.
R4.1: the admissible situationsR41: P1 → P1
pre "f ∈ F_NSec ∪ (F_ASec - fct s)"
in In "[Load Pmf f v]"
out Out "[Ok]"
post valF := "valF s(f 7→v)"
R4.2: all other casesR42: ph → ph
pre "f /∈ F_NSec ∪ (F_ASec - fct s) ∨ sb 6= Pmf ∨ ph 6= P1"
in In "[Load sb f v]"
out Out "[No]"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 142
LKW Model: R5.1
R5.1 thru R5.3: the effects of attacks
Special “spy” input models any attempts to tamper with the chip
and to read security-relevant objects via physical probing on side
channels (by mechanical, electrical, optical, and/or chemical means),
e.g. differential power analysis or inspection with microscope
Modeling physical attacks in more detail is not feasible:
would require a model of physical hardware.
R5.1: the innocent case of reading non-security-relevant objects in any
regular phase, which actually reveals the requested information.
R51: ph → ph
pre "on /∈ Sec", "ph 6= Error"
in In "[Spy on]"
out Out "case val s on of None ⇒ [] | Some v ⇒ [Val v]"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 143
LKW Model: R5.2
R5.2: attempt to read security-relevant objects in a regular phase.
The requested object may be revealed or not. If a secret is leaked,
the chip has to detect this and enter the error phase.
“Destructive reading”: attacks may reveal information even about
security-relevant objects, but after the first of any such attacks, the
processor hardware will be “destroyed”, i.e. cannot be used regularly.
R52: ph → Error
pre "on ∈ Sec", "v ∈ {[],[Val (the (val s on))]}", "ph 6= Error"
in In "[Spy on]"
out Out "v"
post "any"
R52’:ph → ph
pre "on ∈ Sec", "ph 6= Error"
in In "[Spy on]"
out Out "[]"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 144
LKW Model: R5.3R5.3: in the error phase no (further) information is revealed.
R53: Error → Error
in In "[Spy on]"
out Out "[]"
post "any"
R5.2 and R5.3 ⇒ the attacker may obtain (the representation of)
at most one security-relevant object from the chip memory.
Such singleton leakage is harmless!
All data stored on the chip is encrypted. The value obtained may be
the encryption key itself: no further data item, in particular none
encrypted with the key, can be obtained.
encrypted value: attacker cannot any more extract the respective key.
Both cases not helpful to the attacker.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 145
LKW Model: Rule features
R52: ph → Error
pre "ph 6= Error", "oname ∈ Sec",
"v ∈ {[], [Val (the (val σ oname))]}"
in In "[Spy oname]"
out Out "v"
post "any"
Typical:
Both input and output
Underspecification
Nondeterminism (2 ×)
Generic transitions
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 146
LKW Model: ISM Runs
typesSLE66_trans = "(unit, interface, message, SLE66_state) trans"
constdefsTrans :: "SLE66_trans set" — all possible transitions"Trans ≡ trans SLE66.ism"
TRuns :: "(SLE66_trans list) set" — all possible transition sequences"TRuns ≡ truns SLE66.ism"
Runs :: "(SLE66_state list) set" — all possible state sequences"Runs ≡ runs SLE66.ism"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 147
LKW Model of the Infineon SLE66
• The SLE 66 family
• LKW Model
+ Security Properties
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 148
LKW Model: Security Objectives
In (confidential) original security requirements specification by Infineon:
SO1. “The hardware must be protected against
espionage of the security functionality.”
SO2. “The hardware must be protected against
unauthorised modification of the security functionality.”
SO3. “The information stored in all memory devices
must be protected against unauthorised access.”
SO4. “The information stored in all memory devices
must be protected against unauthorised modification.”
SO5. “It must not be possible to execute the test routines of the STS
test mode without authorisation.”
Later, additional requirements were added:
SO[1+2]’. confidentiality+integrity of Smartcard Embedded Software.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 149
LKW Model: Formalized Security Objective FSO1
FSO1: in any sequence ts of transitions performed by the chip,if the chip outputs a value v representing the code ofany security-relevant function during its hitherto life ts,then the next state is in the error phase, or the output wasdue to a function call by the processor manufacturer.theorem FSO1: " [[ts ∈ TRuns; ((p,(ph,s)),c,(p’,(ph’,s’))) ∈ set ts;
p’ Out = [Val v]; v ∈ ValF_Sec (truns2runs ts) ]] =⇒ph’ = Error ∨ (∃ fn. p In = [Exec Pmf fn])"
The set ValF_Sec r holds the code of all security-relevant functionspresent anywhere in a run r :constdefsValF_Sec :: "SLE66_state list ⇒ val set"
"ValF_Sec r ≡⋃{ran (valF sbF_Sec) | ph s. (ph,s) ∈ set r}"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 150
LKW Model: Proof of FSO1 (1)
Proof of FSO1 by
• unfolding some definitions, e.g. of the SLE 66 ISM
• applying properties of auxiliary concepts like truns2runs
• a case split on all possible transitions
Isabelle solves most of the cases automatically (with straightforward
term rewriting and purely predicate-logical reasoning), except two:
R2.1 (normal function execution) is handled using Axiom3:In phase 2, a function cannot reveal (by “guessing” or by accident)any members of ValF_Sec r
Axiom3: " [[r∈Runs; (P2,s)∈set r; f∈fct s ]]=⇒ output f s /∈ValF_Sec r"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 151
LKW Model: Proof of FSO1 (2)
R5.1 (harmless Spy attack) relies on the lemma
" [[r ∈ Runs; (ph, s) ∈ set r; n /∈ Sec; val s n = Some v ]] =⇒ v /∈ ValF_Sec r"
which in turn relies on Axiom4:If a function can be referenced in two (different) ways and one ofthem declares it to be security-relevant, the other does the same.Axiom4: " [[r ∈ Runs;
(ph, s) ∈ set r; (ph’, s’) ∈ set r;
val s n = Some v; val s’ n’ = Some v;
n ∈ Sec]] =⇒ n’ ∈ Sec"
When machine-checking the orginal pen-and-paper proofs,
we noticed that Axiom4 was missing!
Such experience demonstrates importance of machine support
when conducting formal analysis.Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 152
LKW Model: FSO21
Translation of SO2 splits into two parts: overwriting and deletion.
FSO21’: for any transition not ending in the error phase,if a security-relevant function g is present in both the pre-stateand the post-state, the code associated with it stays the same:theorem FSO21’: " [[((p,(ph,s)),c,(p’,(ph’,s’)))∈Trans; ph’ 6= Error;
g ∈ fct s∩fct s’∩F_Sec]] =⇒ valF s’ g = valF s g"
This is a generalization of the original FSO21, to reflect
the extensions made to the Load operation in rule R41:
We do not compare the initial and current values of g
but the previous and current values of g
; takes into account also functions added in the meantime
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 153
LKW Model: Proof of FSO21
Proof of FSO21 by case distinction over all possible transitions.
Most cases are trivial except where function execution may change
the stored objects (as described by R03, R13, and R21).There, invariance of security-relevant functions g is needed,
which follows easily from Axiom1 and Axiom2:
Security-relevant functions do not modify security-relevant functions:Axiom1: "f∈fct s∩F_Sec =⇒ valF (change f s)bF_Sec = valF sbF_Sec"
In comparison to the version of this axiom in the original model,
the scope of functions f has been extended from “initially available”
to “security-relevant”, reflecting the changes to rule R41.
Also non-security-relevant functions do not modify s.-r. functions:Axiom2: "f∈fct s∩F_NSec =⇒ valF (change f s)bF_Sec = valF sbF_Sec"Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 154
LKW Model: FSO22
FSO22: similarly to FSO21’,for any transition within the same phase that is not the error phase,the set of existing security-relevant functions is non-decreasing:
theorem FSO22: " [[((p,(ph,s)),c,(p’,(ph’,s’)))∈Trans; ph’ 6= Error;
ph = ph’ ]] =⇒ fct s∩F_Sec ⊆ fct s’∩F_Sec"
Proof: analougous of FSO21’.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 155
LKW Model: FSO3
FSO3: when trying to get hold of a security-relevant data object on,if the attacker obtains a security-relevant value,then the chip enters the error phase:
theorem FSO3 :" [[((p,(ph,s)),c,(p’,(ph’,s’)))∈Trans; p In = [Spy on];
on ∈ Sec; p’ Out 6= []]] =⇒ ph’ = Error"
Proof: by case distinction.
FSO13: once the chip is in the error phase, it stays thereand the only possible output is the serial number:
theorem FSO13: " [[((p,(ph,s)),c,(p’,(ph’,s’)))∈Trans; ph = Error;
p’ Out = [Val v] ]] =⇒ v = SN ∧ ph’ = Error"
Proof: by case distinction.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 156
LKW Model: FSO4
FSO4: for any transition not ending in the error phase,if it changes the state,this is done in a well-behaved way: s’ is derived from s . . .
• via the desired effect of executing an existing function, or• there is a phase change where only test functions are affected, or• only a single function f is affected by a Load operation:
theorem FSO4:
" [[((p,(ph,s)),c,(p’,(ph’,s’))) ∈ Trans; ph’ 6= Error ]] =⇒s’ = s ∨(∃ sb f . p In = [Exec sb f] ∧ f ∈ fct s ∧ s’ = change f s) ∨(ph’ 6=ph ∧ valD s’ = valD s ∧ valF s’b(-FTest) = valF
sb(-FTest))∨(∃ sb f v. p In = [Load sb f v] ∧
valD s’ = valD s ∧ valF s’b(-{f}) = valF sb(-{f}))"
Proof: by case distinction.Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 157
LKW Model: FSO5
FSO5: in any sequence of transitions performed by the chip,any attempt to execute a test function not issuedby the processor manufacturer is refused :
theorem FSO5: " [[ts ∈ TRuns; ((p,(ph,s)),c,(p’,(ph’,s’))) ∈ set ts;
p In = [Exec sb f]; f ∈ FTest]] =⇒sb = Pmf ∨ s’ = s ∧ p’ Out = [No]"
A second omission of the LKW model was:
In the proof of the security objective FSO5, an argumentation
about the accessibility of certain functions was not given.
We fix this by introducing an auxiliary property
and proving it to be an invariant of the ISM.
As usual, finding the appropriate invariant was the main challenge.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 158
LKW Model: Proof of FSO5 with invariant
The invariant states that
• in phase 1, the test functions from FTest0 have been disabled• in phase 2, all test functions have been disabledconstdefsno_FTest_invariant :: "SLE66_state ⇒ bool"
"no_FTest_invariant ≡ λ(ph,s). ∀ f ∈ fct s.
(ph = P1 −→ f /∈ FTest0) ∧ (ph = P2 −→ f /∈ FTest)"
When proving the invariant, 14 of the 19 cases are trivial.
The remaining ones require simple properties of the set FTest,
and two of them require additionally Axiom1 and Axiom2.
The invariant implieslemma P2_no_FTest:
" [[(P2,s) ∈ reach SLE66.ism; f ∈ fct s ]] =⇒ f /∈ FTest"
Exploiting the lemma for the case of rule R21, we can prove FSO5.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 159
LKW Model: Conclusion
Abstract specification: ISM + a few axioms, e.g.
Axiom1: "f∈fct s∩F_Sec =⇒ valF (change f s)bF_Sec = valF sbF_Sec"
Security objectives: predicates on the system behavior, e.g.
theorem FSO5: " [[ts ∈ TRuns; ((p,(ph,s)),c,(p’,(ph’,s’))) ∈ set ts;
p In = [Exec sb f]; f ∈ FTest]] =⇒sb = Pmf ∨ s’ = s ∧ p’ Out = [No]"
Experience:
• Detected omissions: one axiom, one invariant
• Isabelle proofs: just a few steps, 50% automatic
• New requirements cause only slight changes
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 160
Contents
• Introduction
• Access Control
• Information Flow
• Cryptoprotocol Analysis
• Evaluation & Certification
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 161
Outline
• Denning model
• Noninterference
� Classical notion, unwinding
� Access control interpretation
� Nondeterminism
• Nonleakage and Noninfluence
� Motivation, notion, variants
� Noninfluence
� SLE 66 case study
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 162
Explicit and Implicit Information Flow
• Access control models do not consider covert channels:
information transfer via e.g. timing behavior, or existence of files
� An action causes an information flow from an object x
to an object y, if we may learn more about x by observing y.
� If we already knew x, then no information can flow from x.
• We distinguish:
� Explicit information flow: observing y after the assignment y:=xtells one the value of x.
� Implicit information flow: for conditional if x=0 then y:=1,observing y after the statement may tell one something about x
even if the assignment y:=1 has not been executed.
• Information flow models cover implicit information flow
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 163
The Denning Model (1)
• A formal definition can be given in terms of information theory.
For instance, information flow from x to y is defined by the decrease
in the equivocation (conditional entropy) of x given the value of y.
• The Denning model considers systems with transitions of the form
if P (z1, . . . , zn) then y := f(x1, . . . , xm). Its components are
� A lattice (L,≤) of security labels.
� A set of labeled objects.
� The security policy: a flow is illegal when it violates
Rule: information flow from an object x with label l(x)to an object y with label l(y) is permitted only if l(x) ≤ l(y).
• A system is called secure if there is no illegal information flow.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 164
The Denning Model (2)
• We can distinguish:
� Static enforcement of information flow policies:
a program is checked at compile-time using a type system
→ Language-based security by Sabelfeld, Myers et al.
� Dynamic enforcement using run-time flow control mechanism:
transitions can be secured by adding an extra precondition:
if P (z1, . . . , zn) ∧ sup({l(x1), . . . , l(xm), l(z1), . . . , l(zn)}) ≤ l(y)then y := f(x1, . . . , xm)
• The Denning information flow model covers indirect information flow,
but
Theorem: checking whether a given system is secure in the
Denning information flow model is an undecidable problem.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 165
Outline
• Denning model
+ Noninterference
� Classical notion, unwinding
� Access control interpretation
� Nondeterminism
• Nonleakage and Noninfluence
� Motivation, notion, variants
� Noninfluence
� SLE 66 case study
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 166
Noninterference
• information is classified using domains (security ’levels’)
• users, variables, files, actions, processes, etc. are assigned to domains
• policy: relation (e.g. partial order) on domains, called interference ;
• its complement is called noninterference relation 6;
• if d 6; d′, then ’actions’ of d must not influence d′,
where ’action’ often means: variation of contents
• confidentiality: observations about d impossible for d′
• integrity: changes to d′ impossible for d
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 167
Motivation
Task: Security analysis for Infineon SLE66 smart card processor
SLE66In:message Out:message
Local Variables: map(fn,val) valF map(dn,val) valD
Main concern: confidentiality of on-chip secrets
Initial solution: representation of secret values is not output
Problem: leakage of re-encoded and partial information
Maximal solution: observable output independent of secrets
Approach: some sort of noninterference
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 168
Generic Notions
System model: — Moore automaton
step : action × state → state
run : action∗ × state → state
— also nondeterministic variants
Security model:
domain — secrecy level/area
obs : domain × state → output
dom : action → domain — input domain
Policy or interference relation
; : ℘(domain × domain)— always reflexive, possibly intransitive
Noninterference relation: 6;
downgr.
public
secret
confidential
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 169
Noninterference [GM82/84,Rus92]
Aim: secrecy of the presence/absence of actions
noninterference ≡∀α u. obs(u, run(α, s0)) = obs(u, run(ipurge(u, α), s0))
ipurge(u, α) =”remove from the sequence α all actions that may not
influence u, directly or via the domains of subsequent actions within α”
Observational equivalence/relation
· / · ·l · / · : domain → ℘(state × action∗ × state × action∗)s / α
ul t / β ≡ obs(u, run(α, s)) = obs(u, run(β, t))
noninterference ≡ ∀α u. s0 / αul s0 / ipurge(u, α)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 170
ipurge & sources
ipurge : domain × action∗ → action∗
ipurge(u, []) = []ipurge(u, a _ α) = if dom(a) ∈ sources(a _ α, u)
then a _ ipurge(u, α) else ipurge(u, α)
sources(α, u) = “all domains of actions in α that may influence u,
directly or via the domains of subsequent actions within α”
e.g., v ∈ sources(a1 _ a2 _ a3 _ a4, u)if v = dom(a2) ; dom(a4) ; u (even if v 6; u)
sources : action∗ × domain → ℘(domain)sources([], u) = {u}sources(a _ α, u) = sources(α, u) ∪
{w. ∃v. dom(a) = w ∧ w ; v ∧ v ∈ sources(α, u)}
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 171
Unwinding
Problem: noninterference is global property, to be shown for any α
Idea: induction on α shows preservation of
unwinding relation ∼ between states,
parameterized by domain: domain → ℘(state × state)
— some kind of equality on the sub-state belonging to the domain
— no need to be reflexive, symmetric, nor transitive [Man00/03]
— lifting to sets of domains: sU≈ t ≡ ∀u ∈ U. s
u∼ t
Local properties: essentially su∼ t −→ step(a, s) u∼ step(a, t)
(step consistency, step respect, local respect)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 172
Proof Sketch
Theorem Goal: obs(u, run(α, s0)) = obs(u, run(ipurge(u, α), s0))
Main Lemma:
∀s t. ssources(α,u)≈ t −→ run(α, s) u∼ run(ipurge(u, α), t)
Proof of Theorem: specialize by s = t = s0, use s0
sources(α,u)≈ s0,
and apply output consistency ∀u s t. su∼ t −→ obs(u, s) = obs(u, t)
Proof of Main Lemma: by induction α′ → a _ α′
ssources(a _ α′,u)
≈ t implies
if dom(a) ∈ sources(a _ α′, u)
(step consistency + respect): then step(a, s)sources(α′,u)
≈ step(a, t)
(local respect): else step(a, s)sources(α′,u)
≈ t, then
ind. hypothesis implies run(α′, step(a, s)) u∼ run(ipurge(u, a _ α′), t)Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 173
Step Consistency and Step Respect
weakly step consistent ≡∀a u s t. dom(a) ; u ∧ s
dom(a)∼ t ∧ su∼ t −→ step(a, s) u∼ step(a, t)
~
t step(a,t)
s step(a,s)
~ ~
dom(a)
dom(a)y=2
y=2
uu
u ux=6−2
z=3
z=5
y:=... z:=...x:=x−y
x=6
x=6
x=6−2
step respect ≡ ∀a u s t. dom(a) 6; u ∧ su∼ t −→ step(a, s) u∼ step(a, t)
local respect left ≡ ∀a u s t. dom(a) 6; u ∧ su∼ t −→ step(a, s) u∼ t
local respect right ≡ ∀a u s t. dom(a) 6; u ∧ su∼ t −→ s
u∼ step(a, t)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 174
Outline
• Denning model
• Noninterference
� Classical notion, unwinding
+ Access control interpretation� Nondeterminism
• Nonleakage and Noninfluence
� Motivation, notion, variants
� Noninfluence
� SLE 66 case study
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 175
Access Control Interpretation
More concrete system model with explicit read/write to variables
• State contents maps names to values
contents : state × name → value
• Names of objects a domain is allowed to read or write:
observe : domain → ℘(name)alter : domain → ℘(name)
• The canonical unwinding relation induced by contents and observe:
su∼ t ≡ ∀n ∈ observe(u). contents(s, n) = contents(t, n)
This happens to be an equivalence.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 176
Reference Monitor Assumptions (1)
More concrete conditions implying step consistency and local respect
• RMA1 ≡ output consistent, fulfilled immediately if
the output function yields all values observable for the given domain:
output(u, s) ≡ {(n, contents(s, n)) | n ∈ observe u}
• If action a changes the contents of variable n observable by domain u
and if dom(a) may influence u,
the new value depends only on values observable by dom(a) and u:
RMA2 ≡ ∀a u s t n. sdom(a)∼ t ∧ dom(a) ; u ∧ s
u∼ t ∧n ∈ observe u ∧ (contents(step(a, s), n) 6= contents(s, n) ∨
contents(step(a, t), n) 6= contents(t, n)) −→contents(step(a, s), n) = contents(step(a, t), n)
Note that RMA2 is equivalent to weakly step consistentFormal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 177
Reference Monitor Assumptions (2)
• Any changes must be granted by alter:
RMA3 ≡ ∀a s n.
contents(step(a, s), n) 6= contents(s, n) −→ n ∈ alter(dom(a))
In conjunction with the condition
AC policy consistent ≡ ∀u v. alter(u)∩ observe(v) 6= ∅ −→ u ; v,
this implies local respect:
RMA3 ∧ AC policy consistent −→ local respect
• Hence, enforcement of access control implies security:
theorem access control secure :RMA1 ∧ RMA2 ∧ RMA3 ∧ AC policy consistent −→noninterference
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 178
Nondeterminism
Step : action → ℘(state × state) new: non-unique outcome,
Run : action∗ → ℘(state × state) partiality/reachability
Noninterference ≡ ∀α u β. ipurge(u, α) = ipurge(u, β) −→∀s. (s0, s) ∈ Run(α) −→ ∃t. (s0, t) ∈ Run(β) ∧ obs(u, s) = obs(u, t)
Complications for weak step consistency ⇒stronger notions preserving simultaneous unwinding relation ≈:
uniform step consistency, step respect, and (right-hand) local respect
Requires in general more proof effort, yet not for two important cases:
• functional Step(a)
• two-level domain hierarchy {H,L}
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 179
Outline
• Denning model
• Noninterference
� Classical notion, unwinding
� Access control interpretation
� Nondeterminism
+ Nonleakage and Noninfluence
� Motivation, notion, variants
� Noninfluence
� SLE 66 case study
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 180
Nonleakage and Noninfluence
Event-based systems:
• visibility of actions/events is primary,
• secret state is secondary (via side-effects)
⇒ Noninterference
State-oriented systems:
• secret state is primary,
• actions/events are secondary or irrelevant
⇒ Nonleakage
State-event-systems:
• visibility of actions/events is relevant
• also secrecy in state is essential
⇒ Noninfluence
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 181
Concept
Language-based security: no assignments of high-values
to low-variables, enforced by type system
Semantically: take (x, y) as elements of the state space
with high-level data (on left) and low-level data (on right).
Step function S(x, y) = (SH(x, y), SL(x, y))does not leak information from high to low
if SL(x1, y) = SL(x2, y) (functional independence).
Observational equivalence (x, y)L∼(x′, y′) :←→ y = y′ allows
re-formulation:
sL∼ t −→ S(s) L∼ S(t) (preservation of
L∼)
step consistency + respect
Generalization to action sequences α and arbitrary policies ;Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 182
Definition
nonleakage ≡ ∀α s u t. ssources(α,u)≈ t −→ s / α
ul t / α
“the outcome of u’s observation is independent of those domains
from which no (direct or indirect) information flow is allowed.”
• like Main Lemma, but no purging (visibility of actions irrelevant)
• unwinding relation ∼ is part of the notion:
the secrets for u are those state components not constrained by ∼
• corresponding unwinding theorem: nonleakage implied by
weakly step consistent ∧ step respect ∧ output consistent
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 183
Variants
If (domains of) actions are irrelevant:
weak nonleakage ≡ ∀α s u t. schain(α,u)≈ t −→ s / α
ul t / α
where chain : action∗ × domain → ℘(domain)e.g., v ∈ chain(a1_a2_a3_a4, u) if ∃v′. v ; v′ ; u
• implied by output consistent ∧ weak step consistent respect
Weak combination of step consistency and step respect:
∀s u t. s{w. w ; u}≈ t −→ ∀a. step(a, s) u∼ step(a, t)
If additionally the policy is transitive:
trans weak nonleakage ≡ ∀s u t. s{w. w ; u}≈ t −→ ∀α. s / α
ul t / α
• implied by weak step consistent respect ∧ output consistent
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 184
Noninfluence
combining noninterference and nonleakage:
noninfluence ≡ ∀α s u t. ssources(α,u)≈ t −→s / α
ul t / ipurge(α, u)
• useful if both . . .
� certain actions should be kept secret and
� initially present secret data should not leak
• stronger than noninterference
• implied by
weakly step consistent ∧ local respect ∧ output consistent
• appeared already as Main Lemma (Rushby’s Lemma 5)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 185
Outline
• Denning model
• Noninterference
� Classical notion, unwinding
� Access control interpretation
� Nondeterminism
• Nonleakage and Noninfluence
� Motivation, notion, variants
� Noninfluence
+ SLE 66 case study
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 186
Infineon SLE66 Case Study: Unwinding
Security objective: secret functionality and data is not leaked
Applied notion: nondeterministic transitive weak Nonleakage
Unwinding: equality on: inputs, outputs, non-secret functions and data,
phase, function availability
unwind :: "SLE66_state ⇒ on set ⇒ SLE66_state ⇒ bool"
unwind_def2: "(ph, s) ~A~ (ph’,t) = (ph = ph’ ∧ fct s = fct t ∧(∀ f∈fct s. output f s = output f t) ∧(∀ fn. F fn ∈ A −→ valF s fn = valF t fn) ∧(∀ dn. D dn ∈ A −→ valD s dn = valD t dn))"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 187
Infineon SLE66 Case Study: Theorem
Main proof: weak uni Step consistent respect for U = {-Sec}
Minor complication: invariants required (⇒ reachable states)
theorem noleak_Sec: "∧s t. [[s ∈ reach ism; t ∈ reach ism;
((p,s),c,(p’,s’)) ∈ transs ; s ~-Sec~ t ]] =⇒ ∃ t’.((p,t),c,(p’,t’)) ∈ transs ∧ s’ ~-Sec~ t’"
Results:
• underspecified functions require nonleakage assumptions
• anticipated (non-critical) single data leakage confirmed
• availability of secret functions is leaked
; security objectives clarified: availability is public
• no other information leakedFormal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 188
Conclusion
• refinements and generalizations on Rushby’s work
• introduction of new notions for data flow security:
noninterference + nonleakage = noninfluence
• insights on unwinding and observation relations
• application in machine-assisted security analysis:
� smart card processors (secrecy)
� operating systems (process separation)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 189
Contents
• Introduction
• Access Control
• Information Flow
• Cryptoprotocol Analysis
• Evaluation & Certification
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 190
Motivation then and now
Three can keep a secret, if two of them are dead.
— Benjamin Franklin
We interact and transact by directing flocks of digital packets towards each otherthrough cyberspace, carrying love notes, digital cash, and secret corporatedocuments.Our personal and economic lives rely on our ability to let such ethereal carrierpigeons mediate at a distance what we used to do with face-to-face meetings,paper documents, and a firm handshake.How do we converse privately when every syllable is bounced off a satellite andsmeared over an entire continent?How should a bank know that it really is Bill Gates requesting from his laptop inFiji a transfer of $10,000,000,000 to another bank?
Fortunately, the mathematics of cryptography can help.
— Ron Rivest
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 191
Outline
+ Cryptographic Ingredients
• Crypto Protocols
• Paulson’s Inductive Method
• Model Checking with the AVISPA Tool
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 192
What’s it all about?
• How do we turn untrustworthy channels into trustworthy ones?
Confidentiality: Transmited information remains secret.
Integrity: Information not corrupted (or alterations detected).
Authentication: Principals know who they are speaking to.
• Other goals desirable. E.g., anonymity or timeliness (freshness).
• Cryptography is the enabling technology.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 193
Information hiding
SECRETWRITING
CRYPTOGRAPHY
STEGANOGRAPHY(hidden)
(scrambled)
SUBSTITUTION
TRANSPOSITION
CODE(replace words)
CIPHER(replace letters)
• Cryptology: the study of secret writing.
• Steganography: the science of hiding messages in other messages.
• Cryptography: the science of secret writing.
N.B. Terms like encrypt, encode, and encipher
are often (loosely and wrongly) used interchangeably
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 194
General cryptographic schema
Encryption DecryptionPlaintextCiphertext
Key1 Key2
Plain TextP C P
where Ekey1(P ) = C, Dkey2(C) = P
• Security depends on secrecy of the key, not the algorithm.
• Encryption and decryption should be easy, if keys are known.
• Symmetric algorithms
� Key1 = Key2, or are easily derived from each other.
• Asymmetric or public key algorithms
� Different keys, which cannot be derived from each other.
� Public key can be published without compromising private key.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 195
Communications using symmetric cryptography
1. Alice and Bob agree on a cryptosystem. (Can be performed in public.)
2. Alice and Bob agree on key.
3. Alice encrypts plaintext message using encryption algorithm and key.
4. Alice sends ciphertext to Bob.
5. Bob decrypts ciphertext using the same algorithm and key.
• Good cryptosystem: all security is inherent in knowledge of key
and none is inherent in knowledge of algorithm.
• Benefits: offers confidentiality, integrity, and authentication.
• Main problems:� Keys must be distributed in secret.
� A network of n users requires n× (n− 1)2
keys.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 196
The Diffie-Hellman Key-Exchange
• Initiator I and responder R exchange “half-keys” to arrive at mutual
session key k.
Compute X = g mod px
Compute Y = g mod py
Compute k = Y mod px Compute k = X mod py
Choose g, pGenerate x
I R
Generate y
(1) X [,g,p]
(2) Y
• I and R agree on g > 1 (generator) and a large prime p. May be public.
• Generated keys are equal:
kI = Y x mod p = (gy)x mod p = (gx)y mod p = Xy mod p = kR
• Security (i.e. secrecy of the generated keys) depends on the difficulty
of computing the discrete logarithm of an exponentiated number
modulo a large prime number.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 197
Diffie-Hellman (cont.)
• Unknown if breaking DH as hard as computing discrete logarithms.
• Strength: creates a shared secret out of nothing!
• Strength: if the result is used as short-term session key,
provides perfect forward secrecy!
Even if an attacker acquires all long-term keys and knows all past
(and future) messages encrpyted with the short-term key, he
cannot recover the messge contents.
• Weakness: Keys are unauthenticated!
• Solution: sign the exponents. But this requires public/shared keys!
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 198
Communications using public-key cryptography
Bob: public key KB and private key K−1B .
{{P}KB}K−1
B= P = {{P}K−1
B}KB
Obtain confidentiality of P by
1. Alice and Bob agree on a public-key cryptosystem.
(Can be fixed for a network.)
2. Bob sends Alice his public key KB.
(Or: looked up from a database, attached to message, ...)
3. Alice encrypts message using Bob’s public key KB and sends it to Bob.
4. Bob decrypts message with his private key K−1B .
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 199
Communications using public-key cryptography (cont.)
• Good cryptosystem: all security is inherent in knowledge of key and
none is inherent in knowledge of algorithm.
• It is computationally hard to deduce the private key K−1B from the
public key KB and hence decrypt (private key is sort of trap-door
one-way function).
• Anyone can encrypt a message with KB, which can then be decrypted
only by owner of K−1B .
• Public-key algorithms are less efficient than symmetric ones.
• Eases key-management problem: only two keys per agent.
• Can be used to securely distribute session keys, which are then used
with symmetric algorithms for further traffic (⇒ hybrid cryptosystem).
• Owner of private key K−1B can encrypt messages with it (= digital
signature), which can then be read by everybody using KB.Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 200
The data origin problem
Alice
Tonight atmy place,
Annmy place,Tonight at
• Problem of proof of data origin.
• How do we know, or even prove to others,
that a message originated from a particular person?
• Use a token (a “signature”) that can be applied only by
the right sender and but can be checked by any receiver.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 201
Digital signature implementation
• Public-key algorithms like RSA provide a realization of digital
signatures: {{P}KA}K−1
A= P = {{P}K−1
A}KA
with private K−1A
• Forgery prevented by signing messages with fixed structure, e.g.,
� Message names its sender
1. Alice encrypts message using her private key K−1A and sends it.
2. Bob decrypts message with Alice’s public key KA.
� More efficient: cryptographic hash signed and sent with the message.
• Message can additionally be encrypted for confidentiality.
• Public key cryptography supports both
� checking the origin and authenticity (also possible with shared key)
� proving to others (non-repudiation)
Is this possible using a shared key? No, receiver could forge signatureFormal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 202
Hash Functions
• Hash functions serve as a secure modification detection code (MDC).
• A hash function is a one-way function of all of the bits in a message so
that any change in the bits results in a change in the hash code.
• Properties that a hash function H should satisfy are:
1. H can be applied to a block of data of any size.
2. H produces a fixed-length output.
3. H(x) is relatively easy to compute for any input x.
4. For any given h, it is computationally infeasible to find x such that
h = H(x) (one-way property).
5. For any given x it is computationally infeasible to find y 6= x such that
H(y) = H(x) (weak collision resistance, 2nd-preimage resistance).
6. It is computationally infeasible to find a pair (x, y) such that
H(y) = H(x) (strong collision resistance).
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 203
Applications of Hash Functions
1. Message integrity: modification detection code (MDC)
provides checkable fingerprint.
computesMDC = h(M’)MDC = h(M)
M M’
MDC
(Authenticated)
verifies if
Requires 2nd-preimage resistance and authenticated MDC.
Typical implementation: message authentication code (MAC)
using signed hashes. Additionally gives non-repudiation property.
2. Protect stored passwords:
• Instead of password x the value h(x) is stored in the password file.
• When a user logs in giving a password x′, the system applies the
hash function h and compares h(x′) with the expected value h(x).Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 204
Outline
• Cryptographic Ingredients
+ Crypto Protocols
• Paulson’s Inductive Method
• Model Checking with the AVISPA Tool
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 205
Motivation — bottom up
• How can cryptographic primitives be combined so that the result has
properties that the individual building blocks lack?
• Examples:
� Public keys may be distributed in the clear, but this requires
message authentication.
� Diffie-Hellman creates shared keys “out of nothing”, but also
requires message authentication.
� Digital signatures guarantee message authentication, but not the
timeliness of the message.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 206
Motivation — top down
Example: Securing an e-banking application.
A→ B: “Send $10.000 to account XY Z”B → A: “I’ll transfer it now”
How does B know the message originated from A?
How does B know A just said it?
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 207
Needham-Schroeder Public Key protocol (simplified)
Notation:A,B agent names (Alice, Bob)
Na nonce (“number used only once”) chosen by Alice
Ka Alice’s public key
{X}Ka message X encrypted using Ka
anybody can encryt, but only Alice can recover X
Protocol:
1. A→ B : {Na.A}Kb
2. B → A : {Na.Nb}Ka
3. A→ B : {Nb}Kb
Goals:Alice freshly authenticates Bob, and vice versa
(while the nonces are kept secret)Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 208
Why Are Security Protocols Often Wrong?
Simple algorithms built from simple primitives, but complicated by
• vague specifications
• obscure concepts
• concurrency
• a hostile environment
Theses:
• A protocol without clear goals (and assumptions) is useless.
• A protocol without a proof of correctness is probably wrong.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 209
Dolev-Yao Intruder Model
Intruder has full control over the network — he is the network:
• all messages sent by principals go to the intruder
• operations the intruder can do on messages:
� forward, replay, suppress
� decompose and analyze (if keys known)
� modify, synthesize
� send anywhere
• intruder cannot break cryptography
• intruder may play role(s) of (normal) principals
• intruder gains knowlege of compromised principals
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 210
Outline
• Cryptographic Ingredients
• Crypto Protocols
+ Paulson’s Inductive Method
• Model Checking with the AVISPA Tool
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 211
Paulson’s Inductive Method
Events: Says A B X: A sends B message X A→ B : X
Notes A X : A stores/remembers X
Event trace: sequences of events
A→ B : M1
C → D : P1
B → A : M2
D → C : P2...
Trace-based interleaving semantics: protocol denotes a trace set.
Interleavings of (partial) protocol runs and attacker messages.
Dolev-Yao model: the attacker controls the network.Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 212
Foundations for a formal model
• Inductive definitions are common in mathematics/informatics.
• Example: the set of binary trees T is the smallest set such that:
1. nil ∈ T2. If t1 ∈ T and t2 ∈ T , then node(t1, t2) ∈ T .
• Inductive definitions can be fully formalized in logic.
� As set of Horn Clauses (as above) or
as least fixedpoint of a monotone function over some universe.
� Formalization possible in set-theory or higher-order logic.
� Reasoning principle: (structural) induction over trees, rule induction.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 213
Modeling: protocol as an inductively defined set
A→ B : {A.NA}KB
B → A : {NA.NB}KA
A→ B : {NB}KB
Set P formalizes protocol steps.
0. 〈〉 ∈ P
1. t, A→ B : {A.NA}KB∈ P if t ∈ P and fresht(NA)
2. t, B → A : {NA.NB}KA∈ P if t ∈ P , fresht(NB), and A′ → B : {A.NA}KB
∈ t
3. t, A→ B : {NB}KB∈ P if t ∈ P , A→ B : {A.NA}KB
∈ tand B′ → A : {NA.NB}KA
∈ t
4. t, Spy → B : X ∈ P if t ∈ P and X ∈ synthesize(analyze(knows(Spy , t)))
Rules 0–3 formalize the protocol steps and rule 4 the attacker model.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 214
Agents and Messages
• agent A,B, . . . = Server | Friend i | Spy
• message X,Y, . . .
= Agent A Agent name
| Number N Guessable number, timestamp, ...
| Nonce N Unguessable number
| Key K Crypto key (unguessable)
| Hash X Hashing
| X.Y Compound message
| {X}K Encryption, public- or shared-key
• messages form free algebra (with injective constructors) ;messages have unique structure ; no type-flaw attacks
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 215
Defining Protocols
• traces : ℘(message∗)
• defined inductively:[] ∈ traces
evs ∈ traces X ∈ synth (analz (knows Spy evs))Says Spy B X _ evs ∈ traces
for every transition of agent A sending message Y (containing a fresh
nonce N) to B, if condition P holds and A has received X and noted Z:
evs ∈ traces P Says C A X ∈ set(evs)Nonce N /∈ used evs Notes A Z ∈ set(evs)
Says A B (Y (N)) _ evs ∈ traces
• Suppression/loss of messages implicit
• Agents can be engaged in multiple protocol runsFormal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 216
Freshness• parts ℘(message)→ ℘(message):• components potentially recoverable from a set of messages
• defined inductively:
X ∈ H
X ∈ parts H
X.Y ∈ parts H
X ∈ parts H
X.Y ∈ parts H
Y ∈ parts H
{X}K ∈ parts H
X ∈ parts H
• example: parts {Agent A.Nonce Nb, Key K} ={Agent A.Nonce Nb, Agent A, Nonce Nb, Key K}
• used : event∗→ ℘(message)• components contained in a trace of events:
• defined recursively:
used [] =⋃
A parts (initState A)used (Says A B X _ evs) = parts {X} ∪ used evs
used (Notes A X _ evs) = parts {X} ∪ used evsFormal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 217
Agent Knowledge
• knows : agent→ event∗→ ℘(message)
• defined recursively:
knows C [] = initState C
knows C (Says A B X _ evs) = knows C evs ∪(if C = A ∨ C = Spy then {X} else ∅)
knows C (Notes A X _ evs) = knows C evs ∪(if (C = A ∧ C 6= Spy)∨(A ∈ bad ∧ C = Spy) then {X} else ∅)
• abbreviation: spies ≡ knows Spy
• properties: e.g. X ∈ spies evs −→ X ∈ initState Spy ∨∃A B. Says A B X ∈ set(evs) ∨ (Notes A X ∈ set(evs)∧A ∈ bad):
The intruder has initial knowledge and learns all messages sent,
as well as all messages noted by compromised (“bad”) principals.Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 218
Analyzing Messages
• analz : ℘(message)→ ℘(message):
• components actually derivable
• defined inductively:
X ∈ H
X ∈ analz H
X.Y ∈ analz H
X ∈ analz H
X.Y ∈ analz H
Y ∈ analz H
{X}K ∈ analz H Key (invKey K) ∈ analz H
X ∈ analz H
• NB: no rule for Hash, because hashing is not invertible.
• properties: analz G ∪ analz H ⊆ analz (G ∪H), etc.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 219
Synthesizing Messages
• synth : ℘(message)→ ℘(message):
• messages constructable
• defined inductively:
X ∈ H
X ∈ synth H Agent A ∈ synth H Number N ∈ synth H
X ∈ synth H
Hash X ∈ synth H
X ∈ synth H Y ∈ synth H
X.Y ∈ synth H
X ∈ synth H Key K ∈ H
{X}K ∈ synth H
• properties: analz (synth H) = analz H ∪ synth H, etc.
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 220
Needham-Schroeder-Lowe Protocoltheory NS_Public = Public:
consts ns_public :: "event list set"
inductive ns_public intros
Nil: "[] ∈ ns_public"
Fake: " [[evsf ∈ ns_public; X ∈ synth (analz (spies evsf)) ]]
=⇒ Says Spy B X # evsf ∈ ns_public"
NS1: " [[evs1 ∈ ns_public; Nonce NA /∈ used evs1 ]]
=⇒ Says A B {Nonce NA. Agent A}(pubEK B) # evs1 ∈ ns_public"
NS2: " [[evs2 ∈ ns_public; Nonce NB /∈ used evs2;
Says A’ B {Nonce NA. Agent A}(pubEK B) ∈ set evs2 ]]
=⇒ Says B A {Nonce NA. Nonce NB. Agent B}(pubEK A) # evs2 ∈ ns_public"
NS3: " [[evs3 ∈ ns_public;
Says A B {Nonce NA. Agent A}(pubEK B) ∈ set evs3;
Says B’ A {Nonce NA. Nonce NB. Agent B}(pubEK A) ∈ set evs3 ]]
=⇒ Says A B {Nonce NB}(pubEK B) # evs3 ∈ ns_public"
lemma "∃ NB. ∃ evs ∈ ns_public. Says A B {Nonce NB}(pubEK B) ∈ set evs"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 221
Needham-Schroeder-Lowe: Properties for Alicelemma Spy_analz_priEK :
" [[evs ∈ ns_public ]] =⇒ (Key (priEK A) ∈ analz (spies evs)) = (A ∈ bad)"
lemma no_nonce_NS1_NS2: " [[evs ∈ ns_public;
{Nonce NA. Agent A}(pubEK B) ∈ parts (spies evs);
{NA’. Nonce NA. Agent D}(pubEK C) ∈ parts (spies evs) ]]
=⇒ Nonce NA ∈ analz (spies evs)"
lemma unique_NA:
" [[{Nonce NA. Agent A}(pubEK B) ∈ parts(spies evs);
{Nonce NA. Agent A’}(pubEK B’) ∈ parts(spies evs);
Nonce NA /∈ analz (spies evs); evs ∈ ns_public ]] =⇒ A=A’ ∧ B=B’"
theorem Spy_not_see_NA:
" [[Says A B {Nonce NA. Agent A}(pubEK B) ∈ set evs;
A /∈ bad; B /∈ bad; evs ∈ ns_public ]] =⇒ Nonce NA /∈ analz (spies evs)"
theorem A_trusts_NS2:
" [[Says A B {Nonce NA. Agent A}(pubEK B) ∈ set evs;
Says B’ A {Nonce NA. Nonce NB. Agent B}(pubEK A) ∈ set evs;
A /∈ bad; B /∈ bad; evs ∈ ns_public ]]
=⇒ Says B A {Nonce NA. Nonce NB. Agent B}(pubEK A) ∈ set evs"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 222
Needham-Schroeder-Lowe: Properties for Boblemma B_trusts_NS1 : " [[evs ∈ ns_public; Nonce NA /∈ analz (spies evs);
{Nonce NA. Agent A}(pubEK B) ∈ parts (spies evs) ]] =⇒Says A B {Nonce NA. Agent A}(pubEK B) ∈ set evs"
lemma unique_NB :
" [[CrypT(pubEK A) {|Nonce NA, Nonce NB, Agent B |} ∈ parts (spies evs);
{Nonce NA’. Nonce NB. Agent B’}(pubEK A’) ∈ parts (spies evs);
Nonce NB /∈ analz (spies evs); evs ∈ ns_public ]] =⇒ A=A’ ∧ NA=NA’ ∧ B=B’"
theorem Spy_not_see_NB:
" [[Says B A {Nonce NA. Nonce NB. Agent B}(pubEK A) ∈ set evs;
A /∈ bad; B /∈ bad; evs ∈ ns_public ]] =⇒ Nonce NB /∈ analz (spies evs)"
theorem B_trusts_NS3: " [[A /∈ bad; B /∈ bad; evs ∈ ns_public;
Says B A {Nonce NA. Nonce NB. Agent B}(pubEK A) ∈ set evs;
Says A’ B {Nonce NB}(pubEK B) ∈ set evs; ]]
=⇒ Says A B {Nonce NB}(pubEK B) ∈ set evs"
theorem B_trusts_protocol: " [[A /∈ bad; B /∈ bad; evs ∈ ns_public;
Says B A {Nonce NA. Nonce NB. Agent B}(pubEK A) ∈ set evs;
{Nonce NB}(pubEK B) ∈ parts (spies evs) ]]
=⇒ Says A B {Nonce NA. Agent A}(pubEK B) ∈ set evs"
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 223
Conclusions on Inductive Method
• operational protocol model (event traces)
• focuses on events, states not directly accessible
• rather simple foundations, rather easily understood
• mechanized using a theorem prover like Isabelle/HOL
• proofs are interactive, only semi-automatic
• conducting proofs gives insights in protocol features
• flaws come out in terms of unprovable goals.
• can handle complex protocols (like e.g. SET)
• analysis takes days or weeks
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 224
Outline
• Cryptographic Ingredients
• Crypto Protocols
• Paulson’s Inductive Method
+ Model Checking with the AVISPA Tool
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 225
AVISPA Tool
Output Format (OF)
Intermediate Format (IF)
TranslatorHLPSL2IF
High−Level Protocol Specification Language (HLPSL)
Model−CheckerCL−based SAT−based
SATMC TA4SP
Tree Automata−based
OFMC
On−the−flyModel−Checker Attack Searcher Protocol Analyser
AtSe
avispa script file
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 226
NSPK specified in HLPSL
%% PROTOCOL: NSPK: Needham-Schroeder Public-Key Protocol%% VARIANT: original version (of 1978) without key server%% PURPOSE: Two-party mutual autentication%% MODELER: David von Oheimb, Siemens CT IC 3, January 2005%% ALICE_BOB:%% 1. A - {Na.A}_Kb ----> B%% 2. A <- {Na.Nb}_Ka --- B%% 3. A - {Nb}_Kb ------> B%% PROBLEMS: 3%% ATTACKS: Man-in-the-middle attack,%% where in the first session Alice talks with the intruder as desired%% and in the second session Bob wants to talk with Alice but actually%% talks to the intruder. Therefore, also the nonce Nb gets leaked.%% 1.1 A - {Na.A}_Ki --> i%% 2.1 i(A) - {Na.A}_Kb -> B%% 2.2 i(A) <- {Na.Nb}_Ka - B%% 1.2 A <- {Na.Nb}_Ka - i%% 1.3 A - {Nb}Ki -----> i%% 2.3 i(A) - {Nb}_Kb ----> B%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% HLPSL:
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 227
role alice (A, B: agent,Ka, Kb: public_key,SND, RCV: channel (dy))
played_by A def=
local State : nat,Na, Nb: text
init State := 0
transition
0. State = 0 /\ RCV(start) =|>State’:= 2 /\ Na’ := new() /\ SND({Na’.A}_Kb)
/\ secret(Na’,na,{A,B})
/\ witness(A,B,bob_alice_na,Na’)
2. State = 2 /\ RCV({Na.Nb’}_Ka) =|>State’:= 4 /\ SND({Nb’}_Kb)
/\ request(A,B,alice_bob_nb,Nb’)
end role
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 228
role bob(A, B: agent,Ka, Kb: public_key,SND, RCV: channel (dy))
played_by B def=
local State : nat,Na, Nb: text
init State := 1
transition
1. State = 1 /\ RCV({Na’.A}_Kb) =|>State’:= 3 /\ Nb’ := new() /\ SND({Na’.Nb’}_Ka)
/\ secret(Nb’,nb,{A,B})
/\ witness(B,A,alice_bob_nb,Nb’)
3. State = 3 /\ RCV({Nb}_Kb) =|>
State’:= 5 /\ request(B,A,bob_alice_na,Na)
end role
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 229
role session(A, B: agent, Ka, Kb: public_key) def=
local SA, RA, SB, RB: channel (dy)
composition
alice(A,B,Ka,Kb,SA,RA)/\ bob (A,B,Ka,Kb,SB,RB)
end role
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
role environment() def=
const a, b : agent,ka, kb, ki : public_key,
na, nb,
alice_bob_nb,
bob_alice_na : protocol_id
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 230
intruder_knowledge = {a, b, ka, kb, ki, inv(ki)}
composition
session(a,b,ka,kb)/\ session(a,i,ka,ki)/\ session(i,b,ki,kb)
end role
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
goal
secrecy_of na, nb
authentication_on alice_bob_nb
authentication_on bob_alice_na
end goal
environment()
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 231
NSPK Variant with Key ServerIf Alice/Bob does not know the public key of the peer, asks a key server.
1a. A -------------------- {A.B} ----------> S1b. A <-------------------- {B.Kb}_inv(Ks) - S
1c. A - {Na.A}_Kb --> B
2a. B - {B.A} ----------> S2b. B <- {A.Ka}_inv(Ks) - S
2c. A <- {Na.Nb}_Ka - B3 . A - {Nb}_Kb -> B
role alice (A, B: agent,Ka, Ks: public_key,
KeyRing: (agent.public_key) set,
SND, RCV: channel(dy))played_by A def=
local State : nat,Na, Nb: text,Kb: public_key
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 232
init State := 0
transition
% Start, if alice must request bob’s public key from key serverask. State = 0 /\ RCV(start) /\ not(in(B.Kb’, KeyRing))
=|> State’:= 1 /\ SND(A.B)
% Receipt of response from key serverlearn. State = 1 /\ RCV({B.Kb’}_inv(Ks))
=|> State’:= 0 /\ KeyRing’:=cons(B.Kb’, KeyRing)
% Start/resume, provided alice already knows bob’s public keyknows. State = 0 /\ RCV(start) /\ in(B.Kb’, KeyRing)
=|> State’:= 4 /\ Na’:=new() /\ SND({Na’.A}_Kb’)/\ secret(Na’,na,{A,B})/\ witness(A,B,bob_alice_na,Na’)
cont. State = 4 /\ RCV({Na.Nb’}_Ka)=|> State’:= 6 /\ SND({Nb’}_Kb)
/\ request(A,B,alice_bob_nb,Nb’)
end role
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 233
Attack: Man in the Middle
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 234
Attack on Needham-Schroeder PK (details)
NSPK #1 NSPK #2
A,N{ }A KCA,N{ }A KB
AN ,NB{ }KA AN ,NB{ }KA
NB K{ }C NB K{ }
B
B believes he is speaking with A!
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 235
Examples of kinds of attack
• Replay (or freshness) attack: reuse (parts of) previous messages.
• Man-in-the-middle (or parallel sessions) attack: A↔M↔ B.
• Masquerading attack: pretend to be another principal, e.g.
� M forges source address (e.g., present in network protocols), or
� M convinces other principals that A’s public key is KM.
• Type flaw attack: substitute a different type of message field.
Example: use a name (or a key or ...) as a nonce.
• Reflection attack send transmitted information back to originator.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 236
Attacks on NSPK found with OFMCInvoking avispa NSPK.hlpsl yields two attacks:
% OFMC% Version of 2005/06/14SUMMARYUNSAFE
DETAILSATTACK_FOUND
PROTOCOLNSPK.if
GOALsecrecy_of_nbauthentication_on_bob_alice_na
BACKENDOFMC
COMMENTSSTATISTICSparseTime: 0.00s
searchTime: 0.13s
visitedNodes: 27 nodesdepth: 3 plies
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 237
ATTACK TRACEi -> (a,6): start(a,6) -> i: {Na(1).a}_ki secret(Na(1).na,{a,i})
witness(a.i.bob_alice_na.Na(1),i)i -> (b,3): {Na(1).a}_kb(b,3) -> i: {Na(1).Nb(2)}_ka secret(Nb(2).nb,{a,b})
witness(b.a.alice_bob_nb.Nb(2),i)i -> (a,6): {Na(1).Nb(2)}_ka(a,6) -> i: {Nb(2)}_ki request(a.i.alice_bob_nb.Nb(2),6)i -> (i,17): Nb(2) iknows(Nb(2))i -> (b,3): {Nb(2)}_kb request(b.a.bob_alice_na.Na(1),3)
% Reached State:
% secret(Nb(2).nb,{a,b})% secret(Na(1).na,{a,i})% request(b,a,bob_alice_na,Na(1),3)% witness(a,i,bob_alice_na,Na(1))% request(a,i,alice_bob_nb,Nb(2),6)% witness(b,a,alice_bob_nb,Nb(2))% state_alice(a,b,ka,kb,0,dummy_nonce,dummy_nonce,set_59,3)% state_bob (b,a,ka,kb,5,Na(1) ,Nb(2) ,set_67,3)% state_alice(a,i,ka,ki,4,Na(1) ,Nb(2) ,set_71,6)% state_bob (b,i,ki,kb,1,dummy_nonce,dummy_nonce,set_75,10)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 238
Attack States
Utilizing predicates iknows, secret, witness, and (w)request,which are stable, i.e. once they become true, they stay so.
• Violation of secrecy:
attack_state secrecy_of_x (X,AgentSet) :=secret(X,x,AgentSet) &iknows(X) & not(contains(i,AgentSet))
• Violation of weak authentication:
attack_state weak_authentication_on_a_b_n (A,B,N,SID) :=wrequest(A,B,a_b_n,N,SID) & not(B=i)not(witness(B,A,a_b_n,N))
• Violation of strong authentication: as before, or replay attack
attack_state replay_protection_on_a_b_n (A,B,N,SID1,SID2) :=request(A,B,a_b_n,N,SID1) & not(B=i)request(A,B,a_b_n,N,SID2) & not(SID1=SID2)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 239
What was wrong with NSPK?
The attack:NSPK #1 NSPK #2
A,N{ }A KCA,N{ }A KB
AN ,NB{ }KA AN ,NB{ }KA
NB K{ }C NB K{ }
B
The problem: in step 2: B → A : {NA.NB}KAreplayed.
Lowe’s solution: B should give his name: B → A : {NA.NB.B}KA
Question: Is the improved version now correct?
??
??
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 240
OFMC: Falsification using state enumeration
• Inductive definition corresponds to an infinite tree.
... ... ...
... ...
Says A->B ...
...
Says A->Spy ...Says Spy->A ...
Says A->Spy ...Says B->A ...
...
Says Spy->B ...Says Spy->A ...Says A->Spy ...
• Properties correspond to a subset of nodes, e.g., Na ∈ knows Spy evs.
• State enumeration can be used to find attack in the infinite tree.
• But naive search is hopeless! Challenges:
Tree too wide: the spy is extraordinarily prolific!
Too many interleavings: much “redundant” information.
Below we present three ideas for tackling these problems.Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 241
OFMC Idea 1: symbolic representations...
• Spy very prolific. Generates all instances of
t, Spy → B : X ∈ P if t ∈ P and X ∈ synthesize(analyze(knows(Spy , t)))
• Alternative: allow messages to contain variables. Apply rules using unification.
A→ B : {A.NA}KB
B → A : {NA.NB}KA
A→ B : {NB}KB
a→ Spy : {a.Na}KSpy A→ B : {A.NA}KB
B → A : {NA.NB}KA
A→ B : {NB}KB
a→ Spy : {a.Na}KSpy
Spy → b : X1
A→ B : {A.NA}KB
B → A : {NA.NB}KA
A→ B : {NB}KB
a→ Spy : {a.Na}KSpy
Spy → b : X1 X1 = {X2.X3}Kb
b→ Spy : {X3.Nb}KX2
A→ B : {A.NA}KB
B → A : {NA.NB}KA
A→ B : {NB}KB
a→ Spy : {a.Na}KSpy
Spy → b : {X2.X3}KbX1 = {X2.X3}Kb
b→ Spy : {X3.Nb}KX2
Spy → a : {X3.Nb}KX2
A→ B : {A.NA}KB
B → A : {NA.NB}KA
A→ B : {NB}KB
a→ Spy : {a.Na}KSpy
Spy → b : {X2.X3}KbX1 = {a.Na}Kb
b→ Spy : {X3.Nb}KX2
Spy → a : {X3.Nb}KX2
a→ Spy : {Nb}KSpyX2 = a, X3 = Na
A→ B : {A.NA}KB
B → A : {NA.NB}KA
A→ B : {NB}KB
a→ Spy : {a.Na}KSpy
Spy → b : { a .Na}KbX1 = {a.Na}Kb
b→ Spy : {Na.Nb}Ka
Spy → a : {Na.Nb}Ka
a→ Spy : {Nb}KSpyX2 = a, X3 = Na
Spy → b : {Nb}Kb
A→ B : {A.NA}KB
B → A : {NA.NB}KA
A→ B : {NB}KB
a→ Spy : {a.Na}KSpy
Spy → b : { a .Na}Kb
b→ Spy : {Na.Nb}Ka
Spy → a : {Na.Nb}Ka
a→ Spy : {Nb}KSpy
Spy → b : {Nb}Kb
A→ B : {A.NA}KB
B → A : {NA.NB}KA
A→ B : {NB}KB
• For messages X from the Spy: X ∈ synthesize(analyze(knows(Spy , t))).
=⇒ Implement using narrowing with constraints.Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 242
OFMC Idea 2: partial order reduction...
symbolic
reduction
partial−order
representation
• Many messages are redundant. Example:
The Spy isn’t helped by repeating the same transmission.
• Many orderings are redundant. Example:
The Spy need only say X if the recipient immediately acts on it.
• Formally these define equivalence relations on traces that are
respected by security properties.
=⇒ Restrict search to representatives!
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 243
OFMC Idea 3: lazy data structures
• Lazy evaluation as foundation for “on-the-fly” model checking.
1. Apply narrowing with constraints to build infinite search tree.
2. Use partial order reduction to build a reduced tree.
3. Search the reduced tree by iterative deepening.
• Clean division of model, reduction techniques, and search.
� Tasks are efficiently co-routined in a demand-driven fashion.
� Modern compilers (e.g., for Haskell) produce fast binaries.
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 244
EU Project AVISPA: security sensitive protocols• Goal: advance the state-of-the-art so that validation becomes standard practice.
H.323 MT
V−GK MRP H−BE AuF
1.) GRQ( EPID, GKID, 0, CH1, T1, gx, HMACZZ(GRQ))
13.) GCF(GKID, EPID, CH1, CH2, (T13), gy, HMACZZ(W), HMACZZ(GKID), HMACK(GCF))
14.) RRQ(EPID, GKID, CH2, CH3, (T14), HMACK(RRQ))
2.) RIP(...)
15.) RCF(GKID, EPID, CH3, CH4, (T15), HMACK(RCF))
V−BE MRP
4.) 5.) 6.) 7.)
12.) 11.) 10.) 9.) 8.)
3.)
compute DH: gx mod p
compute DH: gy mod p W:= gx ⊕ gy
K := gxy mod p
K := gxy mod p W:= gx ⊕ gy
AuthenticationRequest (GRQ(..), GKID, W, HMAC)
AuthenticationConfirmation (HMACZZ(W), HMACZZ(GKID), HMAC)
• Apply to standardization of IETF, ITU, and W3C protocols.
Authentication: Kerberos, AAA, PANA, http-digestKey agreement: IKEv2Session control: SIP, H323Mobility: mobile-IP, mobile QoS, mobile multi-mediaEnd-to-End and Peer-to-Peer scenarios: SOAP, Geopriv
Formal Security Modeling, LMU Munchen, SS 2005 based on slides by David Basin and Luca Vigano
David von Oheimb 245
Conclusions on Model Checking
• operational protocol model (state transitions)
• focuses on messages and states
• simple foundations, easy to use
• mechanized, many model checkers available
• checking is (almost) automatic
• output gives no insights in protocol features
• flaws come out in terms of counterexmples: attack traces
• can handle industrial-scale protocols (like e.g. H.530)
• analysis takes hours or days
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 246
Contents
• Introduction
• Access Control
• Information Flow
• Cryptoprotocol Analysis
• Evaluation & Certification
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 247
Evaluation & Certification: Goals & General Approach
Goal: Gaining confidence in the security of a system
• What are the goals to be achieved?
• Are the measures employed appropriate to achieve the goals?
• Are the measures implemented correctly?
Approach: assessment (evaluation) of system security by neutral experts
• Understanding how the system’s security functionality works
• Gaining evidence that security functionality is correctly implemented
• Gaining evidence that the integrity of the system is kept
Result: Successful evaluation is awarded a certificate
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 248
History of Evaluation Criteria
1985: TCSEC Trusted Computer System Evaluation Criteria (USA)
Particular security functionalities required
1989-93: German, UK, French, Canadian criteria
1991: ITSEC Information Technology Security Evaluation Criteria
Harmonisation of European criteria
ITSEC assurance levels provide basis for CC assurance levels
1993: Federal Criteria Draft (USA)
Attempt to update TCSEC and harmonise TCSEC+CTCPEC
Introducing Protection Profiles
1999: CC Common Criteria for IT Security Evaluation (ISO/IEC 15408)
Flexible approach (functional and assurance requirements components)
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 249
Common Criteria: Process Scheme
���������
��������� ����
��� ���
�������� ���� ��������� ������������ ������������
���� ����
��������
��������� ������
���������
��� ��� �
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 250
CC: Security Target
• Definition of the Target of Evaluation (TOE)
and separation from its environment
• Definition of the TOE’s security threats, objectives and requirements
• Introduction of TOE Security Functions (TSF):
measures intended to counter the threats
• Determination of Evaluation Assurance Level (EAL)
⇒ The Security Target is the document to which
all subsequent evaluation activities and results refer!
⇒ Interpretation of results is only reasonable if referring to the ST context
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 251
CC: Evaluation Assurance Levels
EAL1: functionally tested
EAL2: structurally tested
EAL3: methodically tested and checked
EAL4: methodically designed, tested, and reviewed,
including security policy model
EAL5: semiformally designed and tested
including formal security policy model
EAL6: semiformally verified design and tested
EAL7: formally verified design and tested
Increasing requirements on scope, depth and rigor
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 252
CC: EAL example: EAL5
In red: additional requirements compared to EAL4
• Complete source code is subject to analysis
• Formal security policy model
• Semiformal description techniques
• Modular design
• Documentation of developer’s tests up to low-level design
• Vulnerability analysis refers to moderate attack potential
• Covert channel analysis
• Comprehensive configuration management
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 253
CC: How to scale an Evaluation
• Separation of TOE and TOE environment
• Detail level of TOE summary specification
• Definition of security objectives
• Definition of security functional requirements
• Strength-of-function claims
• EAL selection
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 254
Contents
• Introduction
• Access Control
• Information Flow
• Cryptoprotocol Analysis
• Evaluation & Certification
Formal Security Modeling, LMU Munchen, SS 2005
David von Oheimb 255
Conclusion
A formal security model is an abstract formal description of a system
(and its environment) that focuses on the relevant security issues.M BA
M
{ N , A }K
{ N , A }K
{ N , N , }K
A
A B
M
A B{ N , N , }KB
A B
A
A
Interpretation
Abstraction
• improves understanding of security issues by
� abstraction: concentration on the essentials helps to keep overview
� systematic approach: generic patterns simplify the analysis
• prevents ambiguities, incompleteness, and inconsistencies
and thus enhances quality of specifications
• provides basis for systematic testing or even formal verification
and thus validates correctness of implementations
⇒ gives maximal confidence in the security of the systemFormal Security Modeling, LMU Munchen, SS 2005
top related