The Spi Calculus A Calculus for Cryptographic
Protocols
Presented By
Ramesh Yechangunja
Introduction
Developed by Martin Abadi and Andrew D.Gordon at the Systems Research Center, it is an extension of the Pi Calculus with cryptographic primitives designed for describing and analyzing cryptographic protocols.
Features
• Reliance on the powerful scoping constructs of the pi calculus
• Radical definition of the environment as an arbitrary spi calculus process
• Representation of security properties, both integrity and secrecy, as equivalences
Basics
• Channels may be restricted, so that only certain processes may communicate on them. (Similar to CSP)
• The scope of the restriction may change during computation. This is termed scope extrusion. (Different from the earlier process calculi)
• An output process ā‹N›.P ā‹N›.P is ready to output is ready to output on channel on channel aa. If an interaction occurs, term . If an interaction occurs, term NN is communicated on is communicated on aa and then process and then process PP runs.runs.
• An An input processinput process a(x).P a(x).P is ready to input is ready to input from channel from channel aa. If an interaction occurs in . If an interaction occurs in which which NN is communicated on is communicated on a, a, then then process process P[N/x]P[N/x] runs. runs.
• A composition P|Q behaves as processes P and Q running in parallel.
• A restriction (vn)P is a process that makes a new, private name n, and then behaves as P.
• A pair splitting process let (x,y) = M in P (x,y) = M in P behaves as behaves as P[N/x][L/y] P[N/x][L/y] if term if term M M is the is the pair pair (N,L).(N,L). Otherwise, the process is stuck. Otherwise, the process is stuck.
In addition spi calculus introduces primitives for shared-key cryptography
• The term {M}N represents the ciphertext obtained by encrypting M under the key N.
• The process case L of {x}N in P attempts to decrypt the term L with the key N. If L is a ciphertext of the form {M}N, then the process behaves as P[M/x]. Otherwise, the process is stuck.
A first cryptographic example
Consider two principals A and B that share a key KAB with a public channel cAB. The protocol is simply that A sends a message M under KAB to B, on cAB.
Message 1 A→B: {M}KAB on cAB
In the spi calculus, we write
A(M) A(M) ≜ ≜ ccABAB ‹{M}‹{M}KKABAB › ›
-
B B c≜ c≜ ABAB(x).case x of (x).case x of {y}{y}KKABAB in F(y) in F(y)
Inst(M) Inst(M) (vK)(A(M)|B)≜ (vK)(A(M)|B)≜
Security properties are expressed as equivalences. We use the following specification:
A(M) A(M) ≜ ≜ ccABAB ‹{M}‹{M}KKABAB › ›
BBspecspec(M) (M) c≜ c≜ ABAB(x).case x of (x).case x of {y}{y}KKABAB in F(M) in F(M)
InstInstspecspec(M) (M) (vK≜ (vK≜ ABAB)(A(M)|B)(A(M)|Bspecspec(M))(M))
-
We obtain the properties:
Authenticity: Inst(M) Inst(M) Inst≃ Inst≃ specspec(M), for all M(M), for all M
Secrecy: Inst(M) Inst(M) ≃ ≃ Inst(M’) Inst(M’) if F(M) ≃if F(M) ≃F(M’),F(M’),
for all M,M’for all M,M’
An example with key establishment
We consider the Wide Mouthed Frog protocol.
1. New key KAB under KAS 2. New key KAB under KSB
3.data under new key KAB
S
A B
The protocol is
Message 1 A→S: {KAB}KAS on cAS
Message 2 S→B: {KAB}KSB on cSB
Message 3 A→B: {M}KAB on cAB
In the spi calculus, we can express it as:
A(M) A(M) (vK≜ (vK≜ ABAB)( )( ccASAS ‹{‹{KKABAB}}KKASAS ›. ›. ccAB AB ‹{M}‹{M}KKABAB ›) ›)
S S c≜ c≜ ASAS(x).case x of (x).case x of {y}{y}KKASAS in in ccSB SB ‹{y}‹{y}KKSBSB › ›
B B c≜ c≜ SBSB(x).case x of (x).case x of {y}{y}KKSBSB in in
ccABAB(z).case z of (z).case z of {w}{w}yy in F(w) in F(w)
Inst(M) Inst(M) (vK≜ (vK≜ ASAS) (vK) (vKSBSB)( A(M)|S|B))( A(M)|S|B)
A complete authentication example ( with a flaw)
Consider a system with a server and n other principals. Each principal has an input channel which is public, namely, C1, C2,…,Cn and Cs. The server shares a pair of keys with each other principal, Ksi and Kis.
We extend the previous example to this n+1 principals:
Message 1 A→S: A,{B,KAB}KAS on cS
Message 2 S→B: {A,KAB}KSB on cB
Message 3 A→B: A,{M}KAB on cB
- An instance of the protocol is determined by a choice
of parties and by the message sent i.e. an instance I is the triple (i,j,M).
i – source address j - destination address Given an instance (i,j,M), the following process
corresponds to role of A:
Send(i,j,M) Send(i,j,M) (vK)(≜ (vK)(≜ ccSS ‹(‹(ii,{,{jj,,KK}}KKiSiS )›| )›| ccjj ‹(‹(ii,{M},{M}KK)›))›)
The following process corresponds to the role of B:
Recv(j) Recv(j) c≜ c≜ jj(y(yciphercipher).case y).case yciphercipher of of {x{xAA,x,xkeykey}}KKSjSj in in
ccjj(z(zAA,z,zciphercipher).[x).[xA, A, zzAA]]
case zcase zciphercipher of {z of {zplain plain }}xxkeykey in F(xin F(xA,A,j, j, zzplainplain))
- The server S is the same for all instances:
S S c≜ c≜ jj(x(xAA,x,xciphercipher).).
ii1..n1..n[x[xAA is is ii] case x] case xcipher cipher of {xof {xBB,x,xkeykey}}KKiSiS inin
jj1..n1..n[x[xBB is is jj] ] ccj j ‹‹ {x{xAA,x,xkeykey}}KKS jS j › ›
where ii1..k 1..k PPi i is the k-way composition PP1 1 |…|P|…|Pkk
Finally we define a whole system, parameterized on a list of instances of the protocol:
Sys(ISys(I1,…, 1,…, IImm) ) (v≜ (v≜ KKssii )(v)(vKKiiss))
(Send(I(Send(I11) |…| Send(I) |…| Send(Imm) |) | !S!S !Recv(1) |…| !Recv(n) )!Recv(1) |…| !Recv(n) )
-
Unfortunately, the protocol is vulnerable to a replay attack that invalidates the authenticity. An attacker can replay messages of one instance and get them mistaken for messages of the other instance.
A complete authentication example (repaired)
The previous protocol is improved by adding nonce handshakes as protection against replay attacks.
The new protocol is:
Message 1 A→S: A on cS
Message 2 S→A: NS on cA
Message 3 A→S: A,{A,A,B,KAB, NS }KAS on cS
Message 4 S→B: * on cB
Message 5 B→S: NB on cS
Message 6 S→B: {S,A,B,KAB, NB }KS B on cB
Message 7 A→B: A,{M }KAB on cB
- In spi calculus, nonces are represented as newly
created names.
Send(i,j,M) Send(i,j,M) ≜ ≜ ccSS ‹‹ii›|›|
cci i (x(xnoncenonce).).
(vK)((vK)(ccSS ‹(‹(ii,{,{ii,,ii,,jj,,K,xK,xnoncenonce}}KKiSiS )›| )›| ccjj ‹(‹(ii,{M},{M}KK)›))›)
S S c≜ c≜ SS(x(xAA). ). ii1..n1..n[x[xAA is is ii] (vN] (vNSS) () (ccii ‹‹NNSS›|›|
ccSS(x’(x’AA,x,xciphercipher).[x’).[x’A A is is ii]]
case xcase xcipher cipher of {yof {yAA,z,zA, A, xxB, B, xxkeykey, , xxnoncenonce}}KKiSiS inin
jj1..n1..n[y[yAA is is ii][z][zA A is is ii][x][xB B is is jj][x][xnonce nonce is Nis NSS]]
((ccjj ‹*›| ‹*›| ccS S (y(ynoncenonce). ). ccjj ‹{S,‹{S,ii,,jj, x, xkeykey,y,ynoncenonce}}KKS jS j ›)) ›))
-
Recv(j) Recv(j) c≜ c≜ jj(w). (vN(w). (vNBB) () (ccSS ‹‹NNBB›|›|
ccjj(y(yciphercipher).).
case ycase yciphercipher of of {x{xSS, x, xA, A, xxB, B, xxkeykey,,yynoncenonce} } KKS j S j inin
jj1..n1..n[x[xSS is S][x is S][xA A is is ii][x][xB B is is jj][y][ynonce nonce is Nis NBB]]
ccjj(z(zAA,z,zciphercipher).[).[ zzA A is xis xAA]]
case zcase zciphercipher of {z of {zplain plain }}xxkeykey in F(in F(ii,,jj, , zzplainplain))))
Sys(ISys(I1,…, 1,…, IImm) ) (v≜ (v≜ KKssii )(v)(vKKiiss))
(Send(I(Send(I11) |…| Send(I) |…| Send(Imm) |) | !S!S !Recv(1) |…| !Recv(n) )!Recv(1) |…| !Recv(n) )
-
The authenticity property is obtained:
Sys(ISys(I1,…, 1,…, IImm) ) ≃ SysSysspecspec(I(I1,…, 1,…, IImm) ) for any instances I I1,…, 1,…, IImm
This holds good because of the nonces.
Secrecy: Sys(ISys(I1,…, 1,…, IImm) ) ≃ SysSysspecspec(J(J1,…, 1,…, JJmm) )
if each pair (I(I1, 1, JJ1 1 ),… (I),… (Im, m, JJmm) ) is
indistinguishable.
Conclusion
• Harder to write protocols but very detailed.• Main advantage is its formal precision• May not be a good tool for finding flaws but
yields more convincing proofs of correctness• Protocols prone to attacks are developed without
explicit specifications for an attacker. Such precise treatments have not been done before.
Top Related