Prepare for your exams
Get points
Guidelines and tips
Sell on Docsity
Docsity AI

Prepare for your exams

Study with the several resources on Docsity

Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips

Sell on Docsity

Docsity AI

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents

20 Points

For each uploaded document

Answer questions

5 Points

For each given answer (max 1 per day)

All the ways to get free points

Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Type Checking for Protocol Security: A Cryptyc Approach - Prof. Dan S. Wallach, Study notes of Computer Science

Rice University Computer Science

Prof. Dan S. Wallach

The use of type checking for validating security protocols through the cryptyc language. The authors discuss the challenges of protocol validation and introduce the concept of using types to direct the proof of security properties. The document also covers the mathematical foundations of cryptyc, its syntax, and the process of checking robustness through nonces and typing rules.

Typology: Study notes

Pre 2010

Uploaded on 08/16/2009

koofers-user-zn1 🇺🇸

10 documents

1 / 7

This page cannot be seen from the preview

Don't miss anything!

Validating Security Protocols

Through Type Checking

Eric Allen and Brian Stoler

COMP 527: Computer Systems Security

December 4, 2001

Protocol validation is hard.

♦We’d like to prove that our protocols are secure.

– Requires a particular notion of proof and security.

♦Automated theorem proving (e.g. BAN Logic).

– May not converge!

– Can be slow.

– No explicit model for the set of possible attacks.

♦Model Checking.

– Can be slow.

Validation via Type Checking

User annotates protocol with types.

– Types direct the proof of security properties.

– Localized analysis: components can be verified

independently.

– Takes time linear in the size of the protocol!

Mathematical Foundations

♦Pi calculus (Milner, 1999).

♦Spi calculus (Abadi and Gordon, 1999).

♦Cryptyc (Gordon and Jeffrey, 2001).

Discover Study notes of Computer Science Rice University

Partial preview of the text

Download Type Checking for Protocol Security: A Cryptyc Approach - Prof. Dan S. Wallach and more Study notes Computer Science in PDF only on Docsity!

Validating Security ProtocolsThrough Type Checking Eric Allen and Brian StolerCOMP 527: Computer Systems SecurityDecember 4, 2001

Protocol validation is hard. ♦^ We’d like to

prove

that our protocols are

secure.

Requires a particular notion of

proof

and

security.

♦^ Automated theorem proving (e.g. BAN Logic).– May not converge!– Can be slow.– No explicit model for the set of possible attacks. ♦^ Model Checking.– Can be slow.

Validation via Type Checking User annotates protocol with

types.

– Types direct the proof of security properties.– Localized analysis: components can be verifiedindependently.– Takes time linear in the size of the protocol!

Mathematical Foundations ♦^ Pi calculus

(Milner, 1999).

♦^ Spi calculus

(Abadi and Gordon, 1999).

♦^ Cryptyc

(Gordon and Jeffrey, 2001).

Cryptyc Language Syntax ♦A program has one client process andany number of server processes.^ – client

name

{^

statement*

server

name

socket

{^

statement

Cryptyc Language Syntax ♦^ new

message

♦^ connect

server-process socket

♦^ input

socket pattern

♦^ output

socket message

♦^ decrypt

message pattern

An Example Process^ client Sender {

connect Receiver socket;new msg;output socket {msg}key; } server Receiver socket {

input socket ctext;decrypt ctext {msg}key; }

What are we trying to prove? ♦^ Protocol is

safe.

– Protocol works correctly on its own (without anopponent). ♦ Protocol is

robustly safe.

– Protocol works correctly even in the presence of anarbitrary opponent process.– The opponent needn’t adhere to our type system!!! ♦ Still need to formalize “works correctly”.

Adding nonce to example^ client

Sender

connect

Receiver

socket;

input

socket

nonce;

new^

msg; begin

msg; output

socket

{msg

,^ nonce

}key;

} server

Receiver

socket

new^

nonce; output

socket

nonce;

input

socket ctext; decrypt

ctext {msg

,^ nonce’

}key;

check

nonce

is^

nonce’;

end^

msg;

}

Types to the Rescue ♦^ Need more annotations to help with proof.– Need to correlate nonces with

effects

: events

occuring during process execution.– Nonces are assigned types parameterized byeffects.– A Nonce type specifies the event it validates.

Types to the Rescue ♦^ Added syntax:^ – cast

nonce

to^

nonce’

: Nonce(

effect

check

nonce

nonce’

: Nonce(

effect*

Typing Rules ♦^ Each process is examined independently. ♦^ Statements are considered in reverse order, withthe effects of each statement accumulated. ♦^ A process type checks if the accumulated effectset is empty.

Effect Rules^ end

e^

^ add

[end

e ]

begin

e^

^ subtract

[end

e ]

cast

n^ to

n’ :Nonce(

e )^

^ add

[e]

check

n^ is

n’ :Nonce(

e )^

subtract

[e]

add^

[check

n ]

new

n^

^ subtract

[check

n ]

Type Checking Sender client

Sender

connect

Receiver

socket;

input

socket

nonce;

new^

msg; begin

msg; cast

nonce

is^

nonce’:Nonce(end msg)

output

socket

{msg,

nonce’}key;

[end^ msg

[]]

[]

Type Checking Receiver^ server

Receiver

socket

new^

nonce; output

socket

nonce;

input

socket

ctext;

decrypt

ctext {msg,

nonce’}key;

check

nonce

is^

nonce’:Nonce(end msg);

end^

msg; }

[end^ msg

[check

nonce

[] ]

Implementation ♦^ Gordon and Jeffrey’s implementation:^ cryptyc.cs.depaul.edu. ♦^ We have reimplemented Cryptyc.– Separated parsing and type-checking phases.– More sophisticated error reporting.– More extensible.

Adding Asymmetric Protocols ♦^ In asymmetric protocols, trust may increase asnew information arises. ♦^ An agent may prove identity by sending back anonce encrypted with a public key ♦^ Add

Type Checking for Protocol Security: A Cryptyc Approach - Prof. Dan S. Wallach, Study notes of Computer Science

Related documents

Partial preview of the text

Download Type Checking for Protocol Security: A Cryptyc Approach - Prof. Dan S. Wallach and more Study notes Computer Science in PDF only on Docsity!

Validating Security ProtocolsThrough Type Checking Eric Allen and Brian StolerCOMP 527: Computer Systems SecurityDecember 4, 2001

Protocol validation is hard. ♦^ We’d like to

prove

that our protocols are

secure.

proof

and

security.

♦^ Automated theorem proving (e.g. BAN Logic).– May not converge!– Can be slow.– No explicit model for the set of possible attacks. ♦^ Model Checking.– Can be slow.

Validation via Type Checking User annotates protocol with

types.

– Types direct the proof of security properties.– Localized analysis: components can be verifiedindependently.– Takes time linear in the size of the protocol!

Mathematical Foundations ♦^ Pi calculus

(Milner, 1999).

♦^ Spi calculus

(Abadi and Gordon, 1999).

♦^ Cryptyc

(Gordon and Jeffrey, 2001).

Cryptyc Language Syntax ♦A program has one client process andany number of server processes.^ – client

name

{^

statement*

name

socket

{^

statement

Cryptyc Language Syntax ♦^ new

message

♦^ connect

server-process socket

♦^ input

socket pattern

♦^ output

socket message

♦^ decrypt

message pattern

An Example Process^ client Sender {

What are we trying to prove? ♦^ Protocol is

safe.

– Protocol works correctly on its own (without anopponent). ♦ Protocol is

robustly safe.

– Protocol works correctly even in the presence of anarbitrary opponent process.– The opponent needn’t adhere to our type system!!! ♦ Still need to formalize “works correctly”.

Adding nonce to example^ client

Types to the Rescue ♦^ Need more annotations to help with proof.– Need to correlate nonces with

effects

: events

occuring during process execution.– Nonces are assigned types parameterized byeffects.– A Nonce type specifies the event it validates.

Types to the Rescue ♦^ Added syntax:^ – cast

Typing Rules ♦^ Each process is examined independently. ♦^ Statements are considered in reverse order, withthe effects of each statement accumulated. ♦^ A process type checks if the accumulated effectset is empty.

Effect Rules^ end

e^

^ add

[end

e ]

begin

e^

^ subtract

[end

e ]

cast

n^ to

n’ :Nonce(

e )^

^ add

[e]

check

n^ is

n’ :Nonce(

e )^

subtract

[e]

add^

[check

n ]

new

n^