Implementation of Improving Automatic Verification of Protocols with XOR

Author: Xihui Chen

Our implementation is based on the work and source code of Ralf Kusters and
Tomasz Truderung.

REQUIREMENTS

In order to use this tool, the following software should be installed:
- SWI-Prolog
- ProVerif
- Compiled version of sec_list (C source file included)

The prototype is implemented using SWI-Prolog Version 5.6.55. 

USAGE

- XOR-redcution Optimized based on Nonce Freshness and XOR-rule
  (Sect. 4.1 and 4.5)

  This optimized reduction is executed by the following command:

  ./mst_fresh <InputFile> <OutputFile> 
  
  InputFile denotes the file containing the original Horn theory of a
  protocol while outputfile is the input for ProVerif.

- Multi-session Transformation and Optimizations (Sect. 4.2 - Sect. 4.5)

  We have two different integrated implementations:

   - mst: tranforms the Horn theory for an RFID protocol to its
     multi-session model, runs all possible optimizations and verifies
     the Horn theory by ProVerif

   - mst_g: transforms the Horn theory for a general protocol to its
     multi-session model, runs optimizations and verifies the Horn
     theory by ProVerif.

  This integrated analysis can be done by the command as follows:  

  ./mst or ./mst_g
 
  A message will be given immediately:
  "Input the protocol name:"

  We assume the input file's name has '.pl' as extension.  For example,
  assume the input file is 'nsl.pl', then the input is
  'nsl'. Afterwards there will be another message asking if secrecy
  checking is needed. The last message is to ask for the number of
  sessions for the transformation:

  'Please enter the number of sessions to process (end with period):'

  An integer number ending with '.' will be a legal input. For
  instance, '2.' means two session model will be generated and
  verified.

RELATED FILES

    mst_g (mst): batch shell scripts for general (RFID) protocols
    integrating multi-session transformation, optimized reduction
    process and verification using ProVerif.

    mst_gsec (mst_sec): transforms the Horn theory of a general (RFID)
    protocol for authentication to the corresponding model for secrecy
    checking. This command is executed as follows:

    ./mst_gsec <inputfile> <outputfile>

    where inputfile is the Horn theory for authentication and
    outputfile is input smiplified for ProVerif to do secrecy
    verification.

   mst_general (mst_rfid): transform the nonce-XOR-linear Horn theory
   for a general (RFID) protocol to its multi-session model and performs
   reduction with optimizations. This command is executed as follows:

   ./mst_general <inputfile> <outputfile> -nsc/sc 

   If secrecy checking is needed, use "-sc" else use "-nsc".

SYNTAX OF MODELLING PROTOCOLS

   The syntax is almost the same as XorProverif except for some additional
   declarations. An input file contains the declarations of functors,
   intruder rules and protocol rules  To expain the details, we
   divide an input file into thefollowing parts:
   
      - functor symbols: All symbols occuring should be declared
        before used in the following form:
   	
   	  fun  <functor>/<arity>.
   	
          For instance, to declare a hash function: 
   	      fun h/1.

      - nonce declaration: The nonces should be declared in order to
        use the optimization.
   
          nonce <nonce>(_,_,_).
    
          Each nonce consists of three parameters. However, they do not
          have to be explicitly assigned. For example, to delcare
          nonce m(a,b,_I):
    
          nonce m(_,_,_).
   
      - intruder facts and rules: Facts and rules are defined as follows:
   
          rule  t1, ..., tn -> t0.
   
      - protocol rules: For each protocol step of a role A, there
        should be a rule of the form:
   
          rule th(a,b,A,l,sid),t1, ... ,tn -> t0.
   
          The function th(a,b,A,l,sid) is to provide the rule's
          information. It means this rule happens between initiator a
          playing role A and receiver b in session sid. There are
          (l-1) steps before it in a run of a. As for RFID protocols,
          each agent plays a specific role, this function can contain
          one parameter fewer indicating the role a plays:
          th(a,b,l,sid).

      - query: The goal (or security requirement) the tool must verify.
   
          query  <t>.
