Verification of Battleship681 Protocol
Charles Smutz
12/4/2007
Abstract: .............................................................................................................................. 3
Background: ........................................................................................................................ 3
Protocol Requirements: ....................................................................................................... 3
Protocol Design:.................................................................................................................. 4
Protocol Specification: ........................................................................................................ 5
Protocol Verification ........................................................................................................... 5
Security Property 1 ......................................................................................................... 6
Security Property 2 ......................................................................................................... 6
Security Property 3 ......................................................................................................... 6
Security Property 4 ......................................................................................................... 6
Security Property 5 ......................................................................................................... 7
Security Property 6 ......................................................................................................... 7
Appendix 1: Battleship Program Flow ............................................................................... 9
Appendix 2: Verification of TLS using AVISPA ............................................................. 11
Specification ................................................................................................................. 11
Visualization: ................................................................................................................ 14
Test Parameters: ............................................................................................................ 16
Results ........................................................................................................................... 16
OFMC ....................................................................................................................... 16
ATSE......................................................................................................................... 16
SATC ........................................................................................................................ 17
TA4SP ....................................................................................................................... 17
Summary ................................................................................................................... 18
Appendix 3: Verification of Battleship681 using AVISPA .............................................. 19
Specification ................................................................................................................. 19
Visualization: ................................................................................................................ 20
Test Parameters: ............................................................................................................ 22
Results ........................................................................................................................... 22
OFMC ....................................................................................................................... 22
ATSE......................................................................................................................... 22
SATC ........................................................................................................................ 23
TA4SP ....................................................................................................................... 23
Summary ................................................................................................................... 24
2
Abstract:
This Battleship681 as defined herein is shown to satisify the requirements of strong
mutual authentication of both players, secrecy and integrity of messages sent between
players, secrecy of ship layout until discovered through gameplay or revealed at the end
of a round, and non-repudiation of gameplay. These properties are verified using the
AVISPA1 tool.
Background:
The Battleship681 protocol was devised specifically to as a protocol over which to
conduct online versions of the popular game Battleship2. Battleship is a strategy game
based on a naval warfare theme. Battleship is played by two players at one time. Each
player places their ships on a grid. Each ship usually occupies a few (2-5) grid points.
The arrangement of each player’s ships is kept secret from their opponent. Alternating
turns, each player guesses at or fires on a grid point. If a ship covering that grid point, the
opponent declares a “hit”. Otherwise, the opponent declares a “miss”. When all grid
points that are covered by a ship have been guessed, or in other words, when all
compartments on a ship are hit, the ship is declared “sunk” by the opponent. Appendix 1
provides the program flow for a reference implementation of a battleship game using the
Battleship681 protocol. The requirements and name of the Battleship681 protocol are
derived from the requirements of the “Major Project” for the ISA681 course at GMU3
and generally accepted rules for the Battleship game.
Protocol Requirements:
The high-level security requirements for the Battleship681 protocol are as follows:
Given the following environment:
□ Game players do not trust each other (they may try to cheat)
□ Attackers may try to monitor and/or tamper with the game and its results
And the requirements imposed by the game:
□ Each player’s ship layout, which is chosen at the start of a round, should be kept
secret from the opponent until it is revealed at the end of the game or revealed
incrementally through guesses
□ Players should not move their ships one the game begins.
1
Automated Validation of Internet Security Protocols and Applications: http://www.avispa-project.org
Battleship (game): http://en.wikipedia.org/wiki/Battleship_(game)
3
Major Project: http://mason.gmu.edu/~rritchey/assignments.html#MP
2
3
The protocol should provide the following security properties:
1. Mutual Authentication of Players
2. Confidentiality (from attackers) of game play (Guesses and answers are not
known to anyone but players.)
3. Integrity (from attackers) of game player (Guesses and answers are only made by
players and can not be modified or spoofed by attackers.)
4. Confidentiality of ship layout (from opponent) during game play (Ship layout
should not be revealed except through guesses and answers.)
5. Non-repudiation of ship layout (Player should be able to verify that ship layout
created by opponent before game play is the same as that claimed at end of game
play.)
6. Non-repudiation of game play (messages and message acknowledgments),
including each move (Player should be able to prove the outcome of game to a
third party. Opponent should not be able to deny game play.)
Protocol Design:
The Battleship681 protocol leverages other protocols such as SSL to provide a secure
channel for communication. Therefore, security properties 1, 2, and 3 are met through the
use of an external protocol. Battleship681 does requirement for the use of a specific
protocol. Furthermore, Battleship681 does not provide any means of specifying the
protocol to be used either before secure channel establishment or verification that the
established channel is indeed secure. For example, on a trusted platform, the channel may
well be a local IPC mechanism such as a UNIX socket. It is expected that most
implementations of the protocol will be used on TCP/IP networks and will leverage
SSL/TLS, SSH, IPSEC, or some other protocol that satisfies security properties 1, 2, and
3. For completeness’s sake and for demonstrative purposes, a formal verification of TLS
is given in Appendix 2.
The remaining 3 security properties are addressed in the protocol natively. The
Battleship681 protocol provides for security property 4 by encrypting a player’s ship
layout with a randomly selected board encryption key and transmitting the encrypted ship
layout to the opponent. Security property 5 is achieved by sending the signature of the
board encryption key to the opponent before the round is started and sending the plaintext
board encryption key at the end of the round. Property 6 is achieved by sending a
signature of each message between the players (which are synchronous). Each message
includes the signature of the previous message which creates a running signature
providing for non-repudiation of not only each message, chains previous messages back
to the encrypted ship layout and board key signature messages at the start of a round.
4
Protocol Specification:
The Battleship681 protocol is specified from one of the two participants’ view as follows
(the other side is symmetric):
1.
2.
3.
4.
Establish secure channel (TLS, SSH, etc)
Send Intialization Message
Receive Intialization Message from opponent
Loop until Termination Message received
{
Send Message || Receive Message
}
5. Optionally, Send Verifcation Message
6. Optionally, Receive Verification Message
Each Message consists of 3 parts: the payload, the conversation signature, and the
message signature. The payload is the data to be communicated. The conversation
signature is the digital signature of from the previous message in the conversation. The
message signature is a digital signature over other 2 parts of the message (payload and
conversation signature).
The Intialization Message payload is an encrypted data item to kept secret during the
length of the game. It is intended that this secret be the ship layout, but this is not
enforced by the protocol. The Initialization Message conversation message contains the
digital signature of the key used for the message payload encryption. This key is hereafter
known as the game board key. The conversation signature of the first Message after the
exchange of Initialization Messages must contain the concatenation of both the message
signatures of the two Initialization Messages. Other message types include: Guess
Message, Answer Message, and Game Abort Message. These other messages must not
reveal anything about the game board key.
It should be noted that this specification leaves many details unspecified. The protocol
provides no method for agreement of crucial details such as details of secure channel
establishment; exchange and verification of public keys used for signatures; negotiation
of cryptographic algorithms, encoding methods, or data representation; determination of
party to send the first message following exchange of the Initialization Messages; rules
for sending the optional messages; etc.
Protocol Verification
Security Properties 1, 2, and 3 are provided through the use of another protocol. In this
verification, TLS is used as a representative protocol to verify completeness of the
Battleship681 protocol using another protocol. In other words, the verification of security
properties 1, 2, and 3 will be exactly the same as those for TLS and should be considered
5
representative of the set of all external protocols that could ensure properties 1, 2, and 3.
Security Properties 4, 5, and 6 are met internally to the protocol.
Security Property 1
Mutual Authentication of Players
Security Property 1 is met through mutual authentication in establishing the secure
channel (client certificate authentication in TLS). Both parties present certificates signed
by a trusted third party and perform signatures on session-specific data. A verification of
TLS using AVISPA, including strong authentication of both parties, is provided in
Appendix 2.
Security Property 2
Confidentiality (from attackers) of game play (Guesses and answers are not known to
anyone but players.)
Security Property 2 is met by encryption of data through the secure channel (TLS). The
TLS protocol4 specifies that application data be encrypted. The verification of TLS in
Appendix 2 proves the secrecy of session keys negotiated between the two players.
Security Property 3
Integrity (from attackers) of game player (Guesses and answers are only made by players
and can not be modified or spoofed by attackers.)
Security Property is met by authentication of data through the secure channel (TLS). The
TLS protocol specifies that application data be authenticated using Message
Authentication Codes (MAC). The verification of TLS in Appendix 2 proves the secrecy
of session keys negotiated between the two players.
Security Property 4
Confidentiality of ship layout (from opponent) during game play (Ship layout should not
be revealed except through guesses and answers.)
Security Property 4 is achieved by encrypting the secret (ship layout) with a unique key
per game (presumably randomly generated) and not revealing the key until the game is
terminated.
4
The Transport Layer Security (TLS) Protocol Version 1.1: http://tools.ietf.org/html/rfc4346
6
It is recognized that the ship layout will be progressively revealed through game play.
Since the game board is of a well known format, the confidentiality of the ship layout is
susceptible to a known-plaintext attack regardless. The secrecy of the ship layout rests on
the secrecy (randomness) of the game board key. No messages reveal or otherwise
weaken this key, including the signature of this key which is included in the Initialization
message.
Secrecy in AVISPA is forward secrecy, or secrecy through the end of the protocol. Since
AVISPA does not provide adequate mechanisms for modeling the secrecy of data up
until a certain point in the protocol, only the Initialization Message of the protocol is
modeled in the verification of the Battleship681 protocol. The ship layout is not revealed
except through game play after the Initialization Message exchange until game
termination. This claim and simplification of the protocol specification rests on the
intuitive argument that the game board key is not included in any form or derivative in
any messages after the initialization phase until termination and that any revelations
concerning the ship layout are made through game play.
The secrecy of the ship layout at the end of the Battleship681 initialization phase is given
in Appendix 3. Portions of the ship layout are revealed until game termination through
game play (Guess Messages and Answer Messages) but not through any other means.
Security Property 5
Non-repudiation of ship layout (Player should be able to verify that ship layout created
by opponent before game play is the same as that claimed at end of game play.)
Security Property 5 is achieved by providing the opponent with the encrypted ship layout
and the signature of the board encryption key during the initialization phase. The
Initialization Messages are signed also. The game board key is revealed at the end of the
game (also signed). If the opponent cheats, the player can prove the inconsistency
through the aforementioned signatures.
AVISPA provides no reasonable mechanisms for verifying the claims of non-repudiation
in this protocol. The argument for the association of the signatures at the start of the game
and the end of the game is made by security property 6. The authentication of the public
keys used for signatures is performed by the secure channel (see security property 1 and
verification in Appendix 2).
Security Property 6
Non-repudiation of game play (messages and message acknowledgments), including each
move (Player should be able to prove the outcome of game to a third party. Opponent
should not be able to deny game play.)
Security Property 6 is achieved by chaining signatures: the signature of the previous
message is included in the message and therefore covered in the signature of the current
message. The inclusion of the previous signature in the current message signature serves
as an acknowledgement of the previous message, and through induction, all message
7
back to the first message in the chain. The first message after the Intialization Messages
includes the concatenation of the signatures of both Intialization Messages. The protocol
is not purely synchronous (a player can send more than one message before it is
acknowledged by the opponent) so game play can only be proven back to the last
message sent by the opponent which is adequate for this protocol.
AVISPA provides no reasonable mechanisms for verifying the claims of non-repudiation
in this protocol. The authentication of the public keys used for signatures is performed by
the secure channel (see security property 1 and verification in Appendix 2).
Conclusion
The AVISPA tool was used to aid in the verification of the security properties of the
Battleship681 protocol. The Battleship681 protocol is shown to meet the security
requirements of strong mutual authentication of players, confidentiality and integrity of
game play (vice non-players), secrecy of the ship layout until revealed through game
play, and non-repudiation of the ship layout and game play.
8
Appendix 1: Battleship Program Flow
The following describes the program flow for the reference implementation of a
networked battleship game based on Battleship681 protocol.
1. Before start-up:
a. User obtains certificate from Battleship CA
i. certificate is encrypted with password/phrase selected by user
2. Program Statup-Up Phase:
a. User presented with connection screen
i. User chooses either server or client
ii. User sets connection settings
1. IP
a. If server, IP is displayed.
b. If client, IP of server must be entered.
2. Port
a. Default: 6464
3. Key Pair
a. User specifies location of PKCS encode keypair
b. User enters password to unlock private key
iii. User clicks connect (or cancel)
1. SSL connection between client and server established
a. server and client certs verified against hardcoded CA
public key
2. If errors occurs, display error to user
a. Errors:
i. Connection Timeout
ii. Certificate Verification Error
iv. Client and Server are notified of identity of other party
3. Game Layout Phase:
a. Each player places his ships using GUI
b. Each player sends layout of board encrypted with randomly generated key and
signature of the randomly generated key.
c. Each player stores opponent’s encrypted board layout and signature of
encryption key.
4. Game Play Phase:
a. Client and Server take turns going first
b. Player sends signed guess to opponent
i. Guess object grid positions
ii. Signature is over toString() of Guess object concatenated with the
signature of the previous message
1. This creates running signature for whole game. Creates long
chain of non-repudiation.
c. Opponent sends Answer signed answer object
9
i. Answer object contains grid positions, impact (hit, sinking of ship
(including which ship), or miss), and running signature.
d. Players alternate until all of one player’s ships are sunk or a player quits
5. Game Verification Phase:
a. Both players send key to decrypt each other’s ship placement
b. Both players verify that ships did not “move” throughout the game and that
answers.
c. Program notifies players of win/loss and asks them if they want to see
verification details
i. Verification details include:
1. Player Identities (certificate)
2. Players’ encrypted board layouts
3. Signatures of keys used to encrypt ship layouts
4. Guesses (including signatures)
5. Answers (including signatures)
6. Players’ board layout encryption keys
ii. Verification is always available on program exit even if connection to
opponent times out (opponent flees) except that board layout will not
be verified (layout encryption keys not available).
6. Game End Phase:
a. If Game finished normally, player can choose 3 options:
i. Play another round with current opponent
1. returns to Game Layout Phase
ii. Play round with a new opponent
1. returns to Program Start-Up Phase
iii. Exit
1. program exits
10
Appendix 2: Verification of TLS using AVISPA
Specification
The following specification is taken from the AVISPA Library of Protocols5.
role alice(A, B : agent,
H, PRF, KeyGen: hash_func,
Ka, Ks: public_key, %% Ks is the public key of a T3P (ie.
CA)
SND, RCV: channel (dy))
played_by A
def=
local Na, Sid, Pa, PMS: text,
Nb: text,
State: nat,
Finished:
hash(hash(text.text.text).agent.agent.text.text.text),
ClientK, ServerK: hash(agent.text.text.hash(text.text.text)),
Kb: public_key,
M: hash(text.text.text)
const sec_clientk, sec_serverk : protocol_id
init
State := 0
transition
1.
%
%
%
%
2.
5
State = 0
/\ RCV(start)
=|>
State' := 2
/\ Na' := new()
/\ Pa' := new()
/\ Sid' := new()
/\ SND(A.Na'.Sid'.Pa')
Since we abstract away from the negotiation
of cryptographic algorithms, here I simply assume
that the server must send back Pa. (Essentially
modelling that the client makes only one offer.)
State = 2
/\ RCV(Nb'.Sid.Pa.{B.Kb'}_(inv(Ks)))
=|>
State' := 3
/\ PMS' := new()
/\ M' := PRF(PMS'.Na.Nb')
The AVISPA Library of Protocols: http://www.avispa-project.org/library/index.html
11
/\
/\
/\
/\
Finished' := H(PRF(PMS'.Na.Nb').A.B.Na.Pa.Sid)
ClientK' := KeyGen(A.Na.Nb'.PRF(PMS'.Na.Nb'))
ServerK' := KeyGen(B.Na.Nb'.PRF(PMS'.Na.Nb'))
SND({PMS'}_Kb'.
{A.Ka}_(inv(Ks)).
{H(Nb'.B.PMS')}_(inv(Ka)).
{H(PRF(PMS'.Na.Nb').
A.B.Na.Pa.Sid)
}_KeyGen(A.Na.Nb'.PRF(PMS'.Na.Nb')))
/\ witness(A,B,na_nb2,Na.Nb')
4.
State = 3
/\ RCV({Finished}_ServerK)
=|>
State' := 5
/\ request(A,B,na_nb1,Na.Nb)
/\ secret(ClientK,sec_clientk,{A,B})
/\ secret(ServerK,sec_serverk,{A,B})
end role
%--------------------------------------------------------------role bob(A, B : agent,
H, PRF, KeyGen: hash_func,
Kb, Ks: public_key,
SND, RCV: channel (dy))
played_by B
def=
local Na, Nb, Sid, Pa, PMS: text,
State: nat,
Ka: public_key
init
State := 1
transition
1.
State = 1
/\ RCV(A.Na'.Sid'.Pa')
=|>
State' := 3
/\ Nb' := new()
/\ SND(Nb'.Sid'.Pa'.{B.Kb}_(inv(Ks)))
/\ witness(B,A,na_nb1,Na'.Nb')
2.
State = 3
/\ RCV({PMS'}_Kb.{A.Ka'}_(inv(Ks)).
{H(Nb.B.PMS')}_(inv(Ka')).
{H(PRF(PMS'.Na.Nb).
A.B.Na.Pa.Sid)
}_KeyGen(A.Na.Nb.PRF(PMS'.Na.Nb)))
=|>
State' := 5
/\ SND({H(PRF(PMS'.Na.Nb).
A.B.Na.Pa.Sid)
}_KeyGen(B.Na.Nb.PRF(PMS'.Na.Nb)))
12
/\ request(B,A,na_nb2,Na.Nb)
end role
%--------------------------------------------------------------------role session(A,B: agent,
Ka, Kb, Ks: public_key,
H, PRF, KeyGen: hash_func)
def=
local
SA, SB, RA, RB: channel (dy)
composition
/\
alice(A,B,H,PRF,KeyGen,Ka,Ks,SA,RA)
bob(A,B,H,PRF,KeyGen,Kb,Ks,SB,RB)
end role
%------------------------------------------------------------role environment()
def=
const na_nb1, na_nb2 : protocol_id,
h, prf, keygen : hash_func,
a, b
: agent,
ka, kb, ki, ks : public_key
intruder_knowledge = { a, b, ka, kb, ks, ki, inv(ki),
{i.ki}_(inv(ks)) }
composition
session(a,b,ka,kb,ks,h,prf,keygen)
/\ session(a,i,ka,ki,ks,h,prf,keygen)
/\ session(i,b,ki,kb,ks,h,prf,keygen)
end role
%----------------------------------------------------------------goal
secrecy_of sec_clientk,sec_serverk % Addresses G7
%Alice authenticates Bob on na_nb1
authentication_on na_nb1 % Addresses G1, G2, G3, G7, G10
%Bob authenticates Alice on na_nb2
authentication_on na_nb2 % Addresses G1, G2, G3, G7, G10
end goal
%-------------------------------------------------------------environment()
13
Visualization:
TLS as defined in AVISPA can be visualized using SPAN6 as follows:
6
Security Protocol ANimator (SPAN) for AVISPA: http://www.irisa.fr/lande/genet/span/
14
15
Test Parameters:
AVISPA version 1.1 was used. The default settings (web interface) were used for each
verification engine except that for the ATSE engine, “Simplify” was unchecked and
“Breadth first” was selected as the “Search Algorithm”.
Results
OFMC
% OFMC
% Version of 2006/02/13
SUMMARY
SAFE
DETAILS
BOUNDED_NUMBER_OF_SESSIONS
PROTOCOL
/home/avispa/web-interface-computation/./tempdir/workfileN22465.if
GOAL
as_specified
BACKEND
OFMC
COMMENTS
STATISTICS
parseTime: 0.00s
searchTime: 0.33s
visitedNodes: 106 nodes
depth: 8 plies
ATSE
%Defaults, no simplify, breadth first
SUMMARY
SAFE
DETAILS
BOUNDED_NUMBER_OF_SESSIONS
TYPED_MODEL
PROTOCOL
/home/avispa/web-interface-computation/./tempdir/workfileN22465.if
GOAL
As Specified
BACKEND
CL-AtSe
16
STATISTICS
Analysed
:
Reachable :
Translation:
Computation:
2735 states
845 states
0.01 seconds
0.35 seconds
SATC
SUMMARY
SAFE
DETAILS
STRONGLY_TYPED_MODEL
BOUNDED_NUMBER_OF_SESSIONS
BOUNDED_SEARCH_DEPTH
BOUNDED_MESSAGE_DEPTH
PROTOCOL
workfileL12844.if
GOAL
%% see the HLPSL specification..
BACKEND
SATMC
COMMENTS
STATISTICS
attackFound
upperBoundReached
graphLeveledOff
satSolver
maxStepsNumber
stepsNumber
atomsNumber
clausesNumber
encodingTime
solvingTime
if2sateCompilationTime
false
true
1
zchaff
11
1
0
0
0.07
0
11.72
boolean
boolean
steps
solver
steps
steps
atoms
clauses
seconds
seconds
seconds
ATTACK TRACE
%% no attacks have been found..
TA4SP
SUMMARY
INCONCLUSIVE
DETAILS
NOT_SUPPORTED
17
PROTOCOL
/home/avispa/web-interface-computation/./tempdir/workfileL12844.if
GOAL
SECRECY
BACKEND
TA4SP
COMMENTS
For technical reasons about non-left-linearity in term rewriting
with tree automaton,
this protocol cannot be checked.
Sorry.
STATISTICS
Translation: 0.00 seconds
Summary
TLS is shown to perform strong authentication of both participants and to successfully
negotiate symmetric keys.
18
Appendix 3: Verification of Battleship681 using AVISPA
Specification
The following specifies one side (both sides are symmetric) of the initialization message
exchange of the Battleship681 protocol:
% Definition of Confidentiality of Gameboard for Battleship681 protocol
% Only first message (message containing gameboard and signature of
gameboard encryption key) from one side is modeled (other way is exact
mirror and can be considered independent)
role alice(
A,B : agent,
Ka : public_key,
SigHash: hash_func,
Signature
L : text,
SND, RCV : channel(dy))
tunnel)
played_by A def=
local
State : nat,
K : symmetric_key
%Alice's public key
%Digest (hash function) for
%Game Board Layout
%Communication Channels (TLS
%Randomly Generated Board Key
init
State := 0
transition
1. State = 0 /\ RCV(start) =|>
State':= 2 /\ K' := new() /\
SND({L}_K'.{SigHash(K')}_inv(Ka).{SigHash({L}_K'.{SigHash(K')}_inv(Ka))
}_inv(Ka)) /\ secret(L, ship_layout, {A})
end role
%——————————————————————————————————————————
role bob(
A,B : agent,
Ka: public_key,
%Alice's public key
SigHash: hash_func,
%Digest (hash function) for
Signature
SND,RCV : channel(dy))
%Communication Channels (TLS
tunnel)
played_by B def=
local
State : nat,
E : text,
X : symmetric_key,
(unknown to Bob)
Db : text,
Dm : text
%Encrypted Game Board Layout
%Randomly Generated Board Key
%Digest of Board Key
%Digest of whole message
19
init
State := 1
transition
1. State = 1 /\
RCV({E'}_(X).{SigHash(X)}_inv(Ka).{SigHash({E'}_(X).{SigHash(X)}_inv(Ka
))}_inv(Ka)) =|>
State':= 3
end role
%——————————————————————————————————————————
role session(
A,B : agent,
Ka: public_key,
SigHash: hash_func,
L : text)
def=
local SA, SB, RA, RB : channel (dy)
composition
alice(A,B,Ka,SigHash,L,SA,RA)
/\ bob (A,B,Ka,SigHash,SB,RB)
end role
%——————————————————————————————————————————
role environment()
def=
const ship_layout : protocol_id,
l : text,
a,b : agent,
ka : public_key,
sighash: hash_func
intruder_knowledge = {a,b,ka,sighash}
composition
session(a,b,ka,sighash,l)
/\ session(a,i,ka,sighash,l)
end role
%——————————————————————————————————————————
goal
secrecy_of ship_layout
end goal
%——————————————————————————————————————————
environment()
Visualization:
Battleship681 Intialization as defined in AVISPA can be visualized using SPAN as
follows:
20
21
Test Parameters:
AVISPA version 1.1 was used. The default settings (web interface) were used for each
verification engine except that for the ATSE engine, “Simplify” was unchecked and
“Breadth first” was selected as the “Search Algorithm”.
Results
OFMC
% OFMC
% Version of 2006/02/13
SUMMARY
SAFE
DETAILS
BOUNDED_NUMBER_OF_SESSIONS
PROTOCOL
/home/avispa/web-interface-computation/./tempdir/workfileOV3473.if
GOAL
as_specified
BACKEND
OFMC
COMMENTS
STATISTICS
parseTime: 0.00s
searchTime: 0.01s
visitedNodes: 4 nodes
depth: 2 plies
ATSE
%ATSE
%Defaults, no simplify, breadth first
SUMMARY
SAFE
DETAILS
BOUNDED_NUMBER_OF_SESSIONS
TYPED_MODEL
PROTOCOL
/home/avispa/web-interface-computation/./tempdir/workfileOV3473.if
GOAL
As Specified
BACKEND
CL-AtSe
22
STATISTICS
Analysed
:
Reachable :
Translation:
Computation:
9 states
4 states
0.00 seconds
0.00 seconds
SATC
%SATMC
SUMMARY
SAFE
DETAILS
STRONGLY_TYPED_MODEL
BOUNDED_NUMBER_OF_SESSIONS
BOUNDED_SEARCH_DEPTH
BOUNDED_MESSAGE_DEPTH
PROTOCOL
workfileOV3473.if
GOAL
%% see the HLPSL specification..
BACKEND
SATMC
COMMENTS
STATISTICS
attackFound
upperBoundReached
graphLeveledOff
satSolver
maxStepsNumber
stepsNumber
atomsNumber
clausesNumber
encodingTime
solvingTime
if2sateCompilationTime
false
true
2
zchaff
11
2
0
0
0.01
0
0.4
boolean
boolean
steps
solver
steps
steps
atoms
clauses
seconds
seconds
seconds
ATTACK TRACE
%% no attacks have been found..
TA4SP
%TA4SP
SUMMARY
INCONCLUSIVE
DETAILS
23
OVER_APPROXIMATION
UNBOUNDED_NUMBER_OF_SESSIONS
TYPED_MODEL
PROTOCOL
/home/avispa/web-interfacecomputation/./tempdir/workfileOV3473.if.ta4sp
GOAL
SECRECY - Property with identitier: ship_layout
BACKEND
TA4SP
COMMENTS
TA4SP uses abstractions '2AgentsOnly'
Use an under-approximation in order to show a potential attack
The intruder might know some critical information
STATISTICS
Translation: 0.00 seconds
Computation 0.28 seconds
Summary
The Initialization Message exchange of the Battleship681 protocol is shown to maintain
secrecy.
24