Introduction to Formal Methods for Information...

Introduction to

Formal Methods forInformation Security

Christoph Sprenger(slides adapted from Luca Vigano)

Department of Computer ScienceETH Zurich

FMsec Module 1, v.1

Christoph Sprenger 1

Information Security

Information (Technology) Security is interdisciplinary.

Formal Methods

Networks Cryptography Operating Systems

Software EngineeringDistributed Computing

Legal Context Business Processes

Databases

IT Security

...

and therein lies, in part, the challenge, excitement, and reward!

FMsec Module 1, v.1 21.09.2009


Information Security @ ETH

• Other offerings AS 2009:

I Applied Security Laboratory (course).I System Development in Event-B (course).I Model checking (course).I Current topics in Information Security (seminar).I Selected projects in Information Security.I (Information Security, core course, SS).

• More information at www.infsec.ethz.ch

• See also courses in Information Security Master track, e.g., onCryptography, Network Security and the others courses offeredby Profs. Maurer, Capkun, Plattner and their groups.


www.infsec.ethz.ch


Formal Methods for Information Security

• Theoretical research

Formal Methods: Techniques and tools based onmathematics and logic that support the specification,construction and analysis of hardware and software systems.

• and its application to practical security problems

in the small, e.g. security protocols,in the large, e.g. distributed security architectures.




Systems can be understood as mathematical objects.

Formal methods based on mathematics and logic should beused to model, analyze, and construct them.

Doing so can substantially improve system security.



Organization of the course• An advanced course.

I Lecturers: Sebastian Modersheim and Christoph Sprenger.I Tutorials: dito.I Format: 2+1, 4 CP, Mon 16–18 and Tue 15–16 (IFW B 42)I Language: English. D fine for questions/written material.

• Grade determined by oral exam (session examination).

I Duration: 15min.I Homeworks are not part of grade but strongly recommended.

• Web resources (slides and exercises).

I http://www.infsec.ethz.ch/education/as09/fmsec.I Slides available after lecture (before whenever possible).I Watch for corrections (new versions with errata lists) before tests.


http://www.infsec.ethz.ch/education/as09/fmsec


Contents of the course

• Complementary to other offerings (cf. previous list & our projects).

• Learning objectives:

I Formal notation for specifying security systems and properties.I Rigorous methods and techniques for validating systems with

respect to their security requirements.I No reliable “bridges” without mathematics.

• Some topics:

I Introduction to formal security models.I Security protocol models and operational semantics.I Automatic and proof-based protocol analysis and development.I Access control mechanisms, models, policies, and logics.I Enforceable properties and runtime monitoring.I and more (information flow? language-based security?).



Road map for Module 1

+ Introduction:

I What is information security?I Security goals, threats, and mechanisms.I Why do we need more rigorous development methods in

information security?

• Formal methods for information security:

I What are formal methods?I What do we gain by applying them?I Where, when, and how to apply formal methods?

• Some cryptography.



Information Security — Past

Security primarily a military concern.



Information Security — Present

• Information Society marked by rapidexpansion of the Internet and convergenceof information and communicationtechnologies.

• Our basic infrastructures are increasinglybased on networked information systems.

Business, finance, communication, energy distribution, taxes,transportation, entertainment, ...

• Security becomes everyone’s concern.I President George Bush admitted he does not send personal emails to his

daughters for fear that his “personal stuff” might end up in the public domain.I Homeland Security and Patriot Act: trade “freedom” for “security”.

You’ve got e-mail... and the boss knows.



An example: privacy, a fundamental good?

• Lyndon B. Johnson, President of the USA 1963-1969:Every man should know that his conversations, hiscorrespondence, and his personal life are private.

• Directive 95/46/EC of the European Parliament:Whereas data-processing systems are designed to serveman; whereas they must respect their fundamental rights andfreedoms, notably the right to privacy ... In accordance with thisDirective, Member States shall protect the fundamental rights andfreedoms of natural persons, and in particular their right to privacywith respect to the processing of personal data.

• Scott McNealy, CEO Sun Microsystems, 1999:

You have no privacy — get over it.FMsec Module 1, v.1 21.09.2009


Is your data worth protecting?

• Your personal data is interesting.

Shopping habits, family status, religion, political party, criminalrecord, vita/career, health, finances, sports/hobbies, ...

• Your data is everywhere and computers are good at collecting it.

Bank: transfers, investments, credit card purchases, taxes.Telephone: source, time, location.Shopping/travel: from (online) shops, loyalty programs.Entertainment: movies watched in hotels (also < 2 minutes).

• Valuable to sales departments, (future) employers, agencies, etc.

Valuable for you?



Example: e-Government and e-Voting

• Potentially a win-win situation.

I For the citizen

=⇒

I and for the government

=⇒

Potential for a tremendous efficiency gain, cost reduction, andservice improvement.FMsec Module 1, v.1 21.09.2009


Example: e-Government and e-Voting

• Threats (sample):

I How will the system ensure that only registered voters vote?I How will it ensure that each voter can only vote once?I How does the system ensure that votes are not later changed

and are correctly tabulated?I How are votes kept private and identities secret?I System availability? Functional correctness?



E-voting — Swiss requirements

Elektronische Wahl- und Abstimmungssysteme und die elektronischeSammlung von Unterschriften mussen unter allen Umstanden sicherfunktionieren und vor moglichen Gefahren und Einwirkungen von aussengeschutzt sein. Sie mussen dabei ebenso viel Sicherheit bieten wiedie gegenwartig geltenden Systeme. Das bedeutet allerdings nichthundertprozentige Sicherheit. Auch das geltende Abstimmungssystem kenntSchwachstellen.Bericht uber den Vote electronique — Chancen, Risiken und Machbarkeitelektronischer Ausubung politscher Rechte”. Report of the Swiss Bundesrat,Jan 9. 2002.

Requirements in practice are difficult to formulate precisely.This is part of the challenge in designing secure systems.FMsec Module 1, v.1 21.09.2009


Example: Public companies, public data• The situation at hand

The latest dot-com casualty, Voter.com, announced plans tosell its list of 170,000 e-mail correspondents, complete withpolitical party affiliations, issues they’re concerned about anddemographic information, such as home zip-codes and theirgender.

— Center for Individual Freedom Newsletter, 2000

• And what might await usGoogle has created an information repository of a sort that the CIAwould envy. It is reported that Google has maintained a record ofessentially every search (including the IP address information, time,etc.) done on their systems, and has developed tools to mine thisvast storehouse.There is no reason to suspect that Google has evil intentions. Butrosy motives don’t provide immunity from the ways in which theirvast machine could someday become an instrument ofgenuine repression despite Google’s best intentions today.

— Lauren Weinstein, The Privacy Forum, 2004FMsec Module 1, v.1 21.09.2009


Example: Government agencies, government data

Activists are demanding that the government halt the program, which linksmunicipal computer systems and gives each Japanese citizen an 11-digitidentification number. The new database stores personal data — names,addresses, date of birth, and the new ID numbers — for each of Japan’s 127million citizens, making it easier for them to obtain documents for a variety ofpublic services and benefits.

At least five municipalities have refused to join the system. Critics say thatID numbers can act as keys to personal data stored at different locations,making it easy for hackers to create mischief. And doubts have emergedover the technical aspects after several municipalities reported computerglitches.

— Reuters Limited, 2002FMsec Module 1, v.1 21.09.2009


e-Hermitism vs. e-Society• The only secure computer is isolated and turned off!

(You have no privacy — get over it.)

The only truly secure system is one that is powered off, castin a block of concrete and sealed in a lead-lined room witharmed guards — and even then I have my doubts.

Eugene H. Spafford, Purdue University, often misquoted as

The only system which is truly secure is one which is switched off andunplugged, locked in a titanium lined safe, buried in a concrete bunker,and is surrounded by nerve gas and very highly paid armed guards. Eventhen, I wouldn’t stake my life on it.



e-Hermitism vs. e-Society• The only secure computer is isolated and turned off!

(You have no privacy — get over it.)

• But we want, and have, an e-society:



Security in the e-Society: security goals• Information Security is CIA.

Confidentiality: No unauthorized access to information.Integrity: No unauthorized modification of information.Availability: No unauthorized impairment of functionality.

• Note that

I “Information” includes data and programs.I CIA all deal with some form of

authorization.Requires some form of authenticationand access control.

I Other security goals can (often) be seenas special cases of CIA.



Security threats

Interception

Interruption

Modification

Fabrication

to data or services

Service or data becomesunavailable or unusable

Unauthorized tampering ofdata or services

Generation of additionaldata or activities

Unauthorized party gains access Confidentiality

Integrity

Availability



Security Mechanisms

We will consider how different mechanisms can be used toachieve goals in the face of threats, and what some of thechallenges are.



Confidentiality

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.



Data integrity

Example Email (or forms, records, ...).

Threat Unallowed modification/falsification.

Mechanism Digital signatures and/or access control.

Challenges PKI and policy management.



Availability

Example Communication with aserver.

Threats Denial of service, break-ins, ...

Mechanism Fire-walls, virus-scanners, backups, redundanthardware, secure operatingsystems, etc.

Challenges Difficult to cover allthreats (and still have a usablesystem).



Other security goals

• Other security goals can (often) be seen as special cases of CIA.

I Anonymity:∗ A condition in which your true identity is not known.∗ Confidentiality of your identity.I Privacy:∗ You choose what you let other people know.∗ Confidentiality of information that you don’t want to share.



Other security goals

• Other security goals can (often) be seen as special cases of CIA.

I Non-repudiation:∗ A message has been sent (or received) by a party and the

party cannot deny having done so.∗ In general: accountability of actions.∗ Integrity of the sender’s (or receiver’s) claimed identity and

integrity of the proof that the message has been sent by thesender (or received by the receiver).

I Authenticity/authentication:∗ Being who you claim to be.∗ Integrity of claimed identity.

• Also process specific requirements: for example, e-voting mustsuitably combine above and more.



In more detail: Authentication (who is who?)

Example

Threats Misuse of identity.

Mechanisms

Individuals: who one is, what one has, or what one knows.Processes, Data: security protocols, digital signatures, etc.

Challenges authentication hardware/mechanisms, protocoldesign/analysis, PKIs.



In more detail: Access control (who has what permission?)

Example Access to data, processes, networks, ...

Threats Unauthorized access of resources.

Mechanisms Declarative and programmatic control mechanisms.

Here database formalizes policy, e.g., lattice-based, RBAC, ...

Challenges Policy design, integration, and maintenance.



Summary: goals, threats, and mechanisms

• Standard breakdown. Important foranalyzing system security relativeto a policy.

• Designing adequate mechanismsis challenging and careful“screening” is not enough.

• History is full of examples of “security breaches” due to poor“security screening”.



A holistic approach to security engineering

• One must thus take a holistic approach to securityengineering.

I Security must be co-designed with the system, not addedon.

I One must understand the tradeoffs and costs involved.

• There are many open questions both at the level of mechanismsand the design/integration process.



Why is it so difficult?• No security without good software.

Behind every computer security problem and malicious attacklies a common enemy — bad software.

J. Viega and G. McGraw: Building Secure Software.

• Software correctness is a general issue, but achievingsecurity is particularly difficult.

The extra twist in the security situation is that a bad guy isactively trying to make your software misbehave.

J. Viega and G. McGraw: Building Secure Software.

• Secure programs live in a hostile world.

I Hackers and pest programs (worms, viruses, ...) are exploitingbugs that would otherwise have little impact.



Building reliable systems• Do software engineering, not mere programming!

• Some aspects of this for secure systems:

I Clarify the objectives early in the development.∗ Careful analysis of security requirements.∗ Precise documentation of security requirements such that all developers

understand them (in the same way!) and it is noticeable if the requirementschange later.

I Reduce the complexity.∗ Apply divide-and-conquer and stepwise refinement.∗ Document your steps and the system architecture.

I Validate carefully that the security requirements are met.∗ Code inspection, walk-through.∗ Verify critical (sub-)systems and requirements.

• Focus of this course: formal model building and validation.

• Other aspects are addressed in security engineering lectureFMsec Module 1, v.1 21.09.2009



• Introduction:



+ Formal methods for information security:


• Some cryptography.




Formal Methods: Techniques and tools based onmathematics and logic that support the specification,construction and analysis of hardware and software systems.

Systems can be understood as mathematical objects.

Formal methods based on mathematics and logic should be

used to model, analyze, and construct them.

Doing so can substantially improve system security.



Formal Methods

• Examples of formal techniques and tools:

I Program logics (Hoare logic, dynamic logic).I Temporal logics (LTL, CTL, TLA, µ-calculus).I Process algebras (CCS, CSP, π-calculus, Spi-calculus).I Abstract data types (CASL, Z).I Development tools (Rodin/Event-B, PVS, VSE).I Theorem provers (Isabelle, Coq, HOL, Inka).I Model checkers (Spin, SMV, Murφ, OFMC, Scyther).

• Specific techniques and tools will be explained when they areneeded during the lecture.



Applying Formal Methods• Objective:

Clarifying requirements and analyzing systems such that securityincidents are prevented (or at least identified).

• Approach:

1. Formalize the system requirements as security properties.2. Construct a formal model of the system’s behavior.

An abstract specification or a concrete program.3. Verify that the system satisfies the properties.

At the level at which the system has been modeled.

• Each individual step has its value.

1. Documents the security requirements in unambiguous way.2. Documents how the system operates or should operate.3. Validates the system with respect to its requirements.



Applying Formal Methods (cont.)

• That is, applying formal methods does not necessarily meanthat all three steps must be performed.

E.g., one may decide to only model the behavior and therequirements of the system without any verification.

• It is also possible to apply formal methods only to a particularlycritical part of the system rather than to the whole system.

• Reality often calls for compromises, so keep these possibilities inmind when considering the application of formal methods.



Formal Security Models• Separate what shall be achieved and how this is done.

systemspecification

securityproperties

proof

How does thesystem operate?

What shallbe achieved?

Does the system meetits requirements?

satisfies

• Formal specification with formal languages.

• Semantics of languages allow for verification.

Rigorous validation with mathematical methods.

• We will see numerous examples in the course.FMsec Module 1, v.1 21.09.2009


Abstract and Concrete Models

• Formal security models can be built at different levels of abstraction.

I Evaluation criteria demand models at level of requirements andsystem architecture (ITSEC, CC).

I Code verification uses program itself as system specification.

• Security models at different levels need to be related.

I Composition of security models.∗ Analogous to composition of system components.∗ Divide-and-conquer approach.

I Refinement of security models.∗ Analogous to stepwise refinement of specifications.∗ Triggered by design decisions, choice of data type, ...

• Two traditions of applying formal methods.

I A posteriori application, i.e. the system has been developed.I A priori application, i.e. during system development.



Mechanisms vs. Models vs. Properties

• Mechanisms do not distinguish how the system operates and howit should operate.

I What shall be validated against what?I Security properties are not obvious from the mechanism, they

need to be documented explicitly.

• Mechanisms constitute only part of the system.

I What do their properties mean for the overall system?

• Distinguish models and mechanisms: a security mechanism is nota security model by itself (although it can occur in the systemspecification of a security model).

I Concrete problems will be explained later in the course.



Formal Methods in IT Security

• Some historical milestones in development:

I 1973 Bell/La Padula’s access control model.1976 application in Multics operating system.

I 1976 Undecidability of safety problem.I 1977 Biba’s access control models for integrity.I 1983 Undecidability of secrecy problem for protocols.I 1987 Security protocol verification tools.I 1989 BAN logic for security protocol analysis.I 1996 MITM attack on Needham-Schroeder Public Key Protocol.I 1996 SDSI.I 1997 SPKI.

Lecture will disentangle historical development.



Summary: Formal Methods in IT Security

• Security is about CIA.

• Formal methods are good for model building, unambiguousdocumentation, and rigorous validation.

• Formal methods can be applied at different levels of abstractionand during different development phases.

• Formal methods provide a basis for verification, but one canbenefit from their application already without verification.

• A formal security model separates what shall be achieved fromhow the system shall operate.




• Introduction:



• Formal methods for information security:


+ Some cryptography.



Some cryptography: road map

+ A brief introduction to cryptography.

I Encryption.I Symmetric-key vs. public-key encryption.

• Public-key cryptography and key distribution.

I The key distribution problem.I The Diffie-Hellman Key-Exchange.



Cryptography: what’s it all about?

• How do we turn untrustworthy channels into trustworthy ones?

Confidentiality: Transmitted information remains secret.Integrity: Information not corrupted (or alterations detected).Authentication: Principals know who they are speaking to.

• Cryptography is the enabling technology.



General cryptographic schema

Encryption DecryptionPlaintextCiphertext

Key1 Key2

Plain TextP C P

where EKey1(P) = C, DKey2(C) = P

• Symmetric algorithms.

I Key1 = Key2, or are easily derived from each other.

• Asymmetric or public key algorithms.

I Different keys, which cannot be derived from each other.I Public key can be published without compromising private key.

• Encryption and decryption should be easy, if keys are known.

• Security depends on secrecy of the key, not the algorithm.



Cryptanalysis

• Cryptanalysis: science of recovering the plaintext from ciphertextwithout the key.

• Always assume attackers know the algorithms used!

I Worst-case analysis and realistic in open systems.I Algorithms should be published to facilitate the evaluation of

their security.

• Contrast with security by obscurity.

Analogy: hide a letter under yourmattress versus lock it in a safe, whosedesign has been published and whose locking mechanismhas withstood attacks from the world’s best safecrackers.



Encryption/decryption

• A, the alphabet, is a finite set.

• M ⊆ A∗ is the message space. M ∈ M is a plaintext (message).

• C is the ciphertext space, whose alphabet may differ fromM.

• K denotes the key space of keys.

• Each e ∈ K determines a bijective function fromM to C, denotedby Ee. Ee is the encryption function (or transformation).

• For each d ∈ K , Dd denotes a bijection from C toM.Dd is the decryption function.

• Applying Ee (or Dd) is called encryption (or decryption).



Encryption/decryption (cont.)

• An encryption scheme (or cipher) consists of a set {Ee : e ∈ K}and a corresponding set {Dd : d ∈ K} with the property that foreach e ∈ K there is a unique d ∈ K such that Dd = E−1

e ; i.e.,

Dd(Ee(m)) = m for all m ∈ M .

• The keys e and d above form a key pair, sometimes denoted by(e, d). They can be identical (i.e., the symmetric key).

• To construct an encryption scheme requires fixing a messagespaceM, a ciphertext space C, and a key space K , as well asencryption transformations {Ee : e ∈ K} and correspondingdecryption transformations {Dd : d ∈ K}.



An example

LetM = {m1,m2,m3} and C = {c1, c2, c3}. There are 3! = 6 bijectionsfromM to C. The key space K = {1, 2, 3, 4, 5, 6} specifies thesetransformations.

E4

E1 E2 E3

E5 E6

m1m2m3

m1m2m3

m1m2m3

m1m2m3

m1m2m3

m1m2m3

c1c2c3

c1 c1

c1 c1 c1

c2 c2

c2c2c2c3 c3 c3

c3c3

Suppose Alice and Bob agree on the transformation E1. To encryptm1, Alice computes E1(m1) = c3. Bob decrypts c3 by reversing thearrows on the diagram for E1 and observing that c3 points to m1.



Symmetric key encryption

• Consider an encryption scheme {Ee : e ∈ K} and {Dd : d ∈ K}.The scheme is symmetric-key if for each associated pair (e, d) it iscomputationally “easy” to determine d knowing only e and todetermine e from d. For example, e = d.

• Other terms: single-key, one-key, private-key, and conventionalencryption.

• A block cipher is an encryption scheme that breaks up theplaintext message into strings (blocks) of a fixed length t andencrypts one block at a time.

• A stream cipher is one where the block-length is 1.



Background: one-way functions

• A function f : X → Y is a one-way function, if f is “easy” tocompute for all x ∈ X, but f −1 is “hard” to compute.

• Example: Problem of modular cube roots.

I Select primes p = 48611 and q = 53993.I Let n = pq = 2624653723 and X = {1, 2, . . . , n − 1}.I Define f : X → N by f (x) = x3 mod n.I Example: f (2489991) = 1981394214. Computing f is easy.I Inverting f is hard: find x which is cubed and yields remainder!

• A trapdoor one-way function is a one-way function f : X → Ywhere, given extra information (the trapdoor information) it isfeasible to find, for y ∈ Im( f ), an x ∈ X where f (x) = y.

• Example: Computing modular cube root above is easy when pand q are known (using ϕ(n) = (p − 1)(q − 1)).



Public-key cryptography

• Public key cryptography is based on two keys: e and d.

I Schema designed so that given a pair (Ee,Dd), knowing Ee it isinfeasible, given c ∈ C to find an m ∈ M where Ee(m) = c. Thisimplies it is infeasible to determine d from e.

I Ee constitutes a trap-door one-way function with trapdoor d.

• Public key as e can be public information:



Example: RSA

• Named after inventors: Rivest, Shamir, Adleman, 1978.

• Published after 1976 challenge by Diffie and Hellman.

• Security comes from difficulty of factoring large numbers.

Keys are functions of a pairs of large, ≥ 100 digits, prime numbers.

• Most popular public-key algorithm.

Used in many applications, e.g., PGP, PEM, SSL, ...

• Requires some basic number theory to appreciate: see literatureand, for instance, the slides of the Information Security lecture.



Some cryptography: road map

• A brief introduction to cryptography.

I Encryption.I Symmetric-key vs. public-key encryption.

+ Public-key cryptography and key distribution.

I The key distribution problem.I The Diffie-Hellman Key-Exchange.



Public-key cryptography: key distribution

Public-key cryptography was born in May 1975, the child of two problems:

the key distribution problem and the problem of signatures. The discovery

consisted not of a solution, but of the recognition that the two problems, each

of which seemed unsolvable by definition, could be solved at all and that the

solutions to both came in one package.

Whitfield Diffie, The first-ten years of public-key cryptography, 1988

We will not consider digital signatures here (see literature andInformation Security lecture).

Let us look at the key distribution problem in more detail.



The key distribution problem

K1

K2K3

K4

K5

• For n = 1000, 499,500 symmetric versus 2000 asymmetric keys.

• Trust:

What good would it do after all to develop impenetrable cryptosystems, if their

users were forced to share their keys with a key distribution center that could be

compromised by either burglary or subpoena?”

Whitfield Diffie, The first-ten years of public key cryptography, 1988FMsec Module 1, v.1 21.09.2009


Asymmetric algorithms for private key distribution

• Public-key infrastructure used to support symmetric cryptography.

Distribute shared keys for faster symmetric algorithms.

• Encryption of m (with public key (n, e))

I choose k randomlyI c = (ke mod n, Ek(m))

• Decryption (with private key d)

I Split c into (c1, c2)I k = cd

1 mod n m = Dk(c2)

• Can we weaken prerequisites?

Can principals agree on a key over an insecure channel?



Background on discrete logarithms

• A primitive root s of a prime number p is a number whose powersgenerate Z∗p = {1, . . . , p − 1}.

Therefore s mod p, s2 mod p, . . ., sp−1 mod p are distinct, i.e., apermutation of Z∗p. Hence:

∀b ∈ Z∗p.∃i ∈ {0, . . . , p − 1}. b ≡ si (mod p)

• Given b ∈ Z∗p, the exponent i above is the discrete logarithm of bfor base s, mod p.

• Computing discrete logarithms appears infeasible.



The Diffie-Hellman Key-Exchange

Basic Diffie-Hellman key-exchange: initiator I and responder Rexchange “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

Security depends on the difficulty of computing the discretelogarithm of an exponentiated number modulo a large prime number.

Unknown if breaking DH as hard as computing discrete logs.



The Diffie-Hellman Key-Exchange (cont.)



Compute k = Y mod px Compute k = X mod py


I R

Generate y

(1) X [,g,p]

(2) Y

• I and R agree on DH group (g, p) (i.e., Z∗p for large prime p and generator g).

I Group (g, p) is typically chosen by I and sent to R; there are well-knowngroups referred to with unique group identifier numbers.

I Group may be implicit (e.g. 2 parties always use same group).

• I generates large (at least 180 bits in length) random integer x and sendshalf-key X = gx mod p (and optionally also the group).

• R generates large random integer y and sends half-key Y = gy mod p.

• I and R compute key k = Y x mod p = Xy mod p.



The Diffie-Hellman Key-Exchange (cont.)

• Strength:

I Creates a shared secret out of nothing!I Key k is at least as strong as the strongest half-key: neither I nor

R can completely sabotage the resulting key.

• Weakness: no authentication of participants, no prevention ofreplay or flooding attacks.

Subject to a number of attacks. Let us see an example.



DOS against Diffie-Hellman

• Denial of Service (DoS) attack on R via flooding:

Attacker sends series ofrequest packets, each withdifferent spoofed source IPaddress Xi, so that R mustprocess each request.

Expensive exponentiationand storage (of ys).

X , X , ..., X1 2 n

Generate seriesof random numbers

Generate y1y1Compute Y = g mod p1

Compute Y = g mod p

ynCompute Y = g mod pn

X [,g,p]n

Generate yn

X [,g,p]2

Choose g, p

I R

Generate y22

y2

1X [,g,p](1)

(2)

(n)

• Weak forms of protection available, e.g.:

I Demand a response from a claimed address.I Make initiator perform some computation.



Cookies against DOSI and R send also random cookies CI and CR, and associate cookiepair with peer’s IP address.

Cookies are either randomly generated numbers, or even better,stateless, e.g. C = hash(IP address, secret).

Messages containing cookiepair associated with different IPaddresses are discarded.

Attacker A must thus completea cookie exchange for eachaddress it spoofs.

A must also be able to read CR,which is sent to spoofed address.



Validate cookieGenerate y

Compute k = Y mod pxyCompute k = X mod p

(2) C , C I R

(1) C I

Generate C R

Generate C I

(3) C , C , X [,g,p] I R

(4) C , C , Y I R

I R


Validate cookie

Cookies also uniquely identify a particular key exchange amongseveral occurring (sequentially or concurrently) between two hosts.FMsec Module 1, v.1 21.09.2009


Group Diffie-Hellman (for three or more parties)Given a Diffie-Hellman group (g, p), three parties Alice, Bob and Carol cangenerate together a secret key k = gxyz mod p by:

1. Alice chooses a random large integer x and sends BobX = gx mod p

2. Bob chooses a random large integer y and sends CarolY = gy mod p

3. Carol chooses a random large integer z and sends AliceZ = gz mod p

4. Alice sends BobZ′ = Zx mod p

5. Bob sends CarolX′ = Xy mod p

6. Carol sends AliceY ′ = Yz mod p

7. Alice computesk = Y ′x mod p

8. Bob computesk = Z′y mod p

9. Carol computesk = X′z mod p

Can be easily extended to more parties by adding more rounds of computations.FMsec Module 1, v.1 21.09.2009


El Gamal variant

• Setup: same as Diffie-Hellman. Public prime p and generator g.

• Moreover, let f be any symmetric encryption function.

• Schema

Step 1 B chooses b and computes β = gb mod p.B→ A: β.

Step 2 A chooses integer a, computes α = ga mod p, andcomputes key k = βa mod p.

A→ B: ( fk(m), α).Step 3 B computes k = αb mod p and uses k to decrypt fk(m).

Red parts are Diffie-Hellman.



Module 2: security protocols

• How can cryptographic primitives be combined so that the resulthas properties that the individual building blocks lack?

• Examples:

I Diffie-Hellman creates shared keys “out of nothing”, but alsorequires message authentication.

I Public keys may be distributed in the clear, but this requiresmessage authentication.

I Digital signatures guarantee message authentication, but notthe timeliness of the message.



Module 2: security protocols (cont.)• Example: Securing an e-banking application.

A→ B: “Send $10,000 to account X”B→ A: “I’ll transfer it now”

I How does B know the message originated from A?I How does B know A just said it?

• Other examples:I Constructing secure channels in wireless networks.I A micropayment scheme for E-Commerce.I An access control system for area-wide ski-lifts.

• How can one build distributed algorithms for doing this?

Solutions involve protocols like IPSEC, KERBEROS, SSH, SSL,SET, PGP... We’ll consider underlying ideas and some exampleprotocols.



BibliographyLecture will be mainly based on journal and conference papers, but see also:

• Ross Anderson. Security Engineering:A Guide to Building DependableDistributed Systems, Wiley, 2001.

• Matt Bishop. Computer Security (Art and Science). Pearson, 2003.

• Dieter Gollmann. Computer Security. Wiley, 2000.

• Charlie Kaufman, Radia Perlman, and Mike Speciner. Network Security:Private Communication in a Public World, Prentice Hall, 2002.

• Wenbo Mao. Modern Cryptography. Prentice Hall, 2003.

• Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone. Handbook ofApplied Cryptography. CRC Press, 1996 (available online).

• Bruce Schneier. Applied Cryptography. John Wiley & Sons, 1996.

• William Stallings. Cryptography and Network Security. Principles and Practice.Prentice Hall, 2003.

• John Viega and Gary McGraw. Building Secure Software. Addison-Wesley,2002.


Introduction to Formal Methods for Information...

Documents

Transcript of Introduction to Formal Methods for Information...