Kant: A Domain-Speciﬁc Language for Modeling Security Protocols

C. Braghin

∗ a

, M. Lilli

, E. Riccobene

, K. Notari and Marian Baba

Department of Computer Science, Universit

a degli Studi di Milano, Italy

Keywords:

Model-Driven Language Engineering, Security Protocol Speciﬁcation and Analysis, Language Validation.

Abstract:

Designing a security protocol is a complex process that requires a deep understanding of security principles

and best practices. To ensure protocol effectiveness and resilience against attacks, it is important to strengthen

security by design by supporting the designer with an easy-to-use, concise, and simple notation to design

security protocols in a way that the protocol model could be easily mapped into the input model a veriﬁca-

tion tool to guarantee security properties. To achieve the goal of developing a DSL language for security

protocol design, working as the front-end and easy-to-use language of a formal framework able to support

different back-end tools for security protocol analysis, we present the abstract and concrete syntaxes of the

Kant (Knowledge ANalysis of Trace) language. We also present a set of validation rules that we have deﬁned

to help the designer, already at design time, to avoid common security errors or to warn him/her regarding

choices that might lead to protocol vulnerabilities. The effectiveness of Kant’s expressiveness is discussed in

terms of a number of case studies where Kant has been used for modeling protocols.

1 INTRODUCTION

Security protocols are a set of procedures deﬁning

how data should be transmitted, encrypted, authen-

ticated, and protected to ensure the security and in-

tegrity of information during communication (Ander-

son and Needham, 1995). Despite their apparent sim-

plicity, designing a security protocol is a complex pro-

cess that requires a deep understanding of security

principles and best practices. Although a large num-

ber of security protocols have been developed and im-

plemented to provide security guarantees, the devel-

opment of security protocols is particularly prone to

errors: many communications protocols do not use

up-to-date security features or implement them incor-

rectly (Basin et al., 2018). Security vulnerabilities

and errors cannot be detected only by functional soft-

ware testing because they appear in the presence of a

malicious adversary. For this reason, many published

protocols have proven to be faulty many years after

their practical usage (Tobarra et al., 2008).

To ensure the protocol’s effectiveness and re-

https://orcid.org/0000-0002-9756-4675

https://orcid.org/0000-0001-7236-9171

https://orcid.org/0000-0002-1400-1026

∗

This work was partially supported by project SER-

ICS (PE00000014) under the MUR National Recovery and

Resilience Plan funded by the European Union - NextGen-

erationEU.

silience against attacks, it is important to strengthen

security at design-time by achieving the so-called se-

curity by design. In fact, defects found after the

design phase are expensive to ﬁx, and the cost in-

creases exponentially during the subsequent develop-

ment phase (Haskins et al., 2004). Thus, protocol de-

sign should be complemented by rigorous analysis,

and formal veriﬁcation of security protocols has be-

come a key issue.

Most of the tools developed in the past for proto-

col veriﬁcation were not widely adopted by the indus-

try, and the reason is strongly related to the fact that

formal method usage requires a strong mathematical

background, which many designers or engineers do

not hold (Davis et al., 2013). Additionally, (i) vali-

dation tools are often based on modeling languages

with poor usability, making the writing of the model

error-prone as well; (ii) the veriﬁcation process is not

a push-bottom activity and requires user intervention

along with the proof and knowledge of the analysis

mechanism; (iii) the veriﬁcation results are often dif-

ﬁcult to interpret and to cross check with the origi-

nal protocol; (iv) veriﬁcation approaches have differ-

ent goals and sometimes the integrated use of various

tools could be useful for more complete protocol anal-

ysis. However, tools integration is difﬁcult to achieve

(Heinrich et al., 2021) since each tool has its own in-

put language and modeling primitives, thus using dif-

ferent tools often requires starting modeling the same

protocol from scratch each time.

Braghin, C., Lilli, M., Notari, E. and Baba, M.

Kant: A Domain-Speciﬁc Language for Modeling Security Protocols.

DOI: 10.5220/0012386400003645

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 12th International Conference on Model-Based Software and Systems Engineering (MODELSWARD 2024), pages 62-73

ISBN: 978-989-758-682-8; ISSN: 2184-4348

In this paper, we present the ﬁrst results of an on-

going research project to provide practitioners with a

formal framework able to support different kinds of

analysis for security protocols, but at the same time

easy to use and with a reduced gap between designer’s

background and formal notations.

Figure 1: APROVER Framework.

Fig. 1 shows the architecture of the APROVER

(Automatic PROtocol VERiﬁer) framework under de-

velopment. We envision it as composed of a model-

ing front-end on top of richer and more speciﬁc mod-

eling, analysis, and implementation back-end frame-

works. Following this rationale, the modeling front-

end should provide an easy-to-use, concise, and sim-

ple notation to design security protocols. By exploit-

ing the model-based software engineering approach,

this could be achieved by deﬁning a DSL (Domain

Speciﬁc Language) for protocol speciﬁcation, and

possibly developing a textual and graphical notation

(with interchangeable models) for it. More speciﬁc

models or code in the target back-end frameworks/-

platforms could be synthesized from these DSL mod-

els by deﬁning/developing suitable model transfor-

mations towards input models of the target back-end

tools. ASMETA (Arcaini et al., 2011) for model sim-

ulation and model checking, PROVERIF (Blanchet,

2001) and TAMARIN (Meier et al., 2013) for trace

analysis, are the tools under consideration as primary

back-end tools, but other back-ends could be inte-

grated into the APROVER framework by exploiting

model transformations.

We here present Kant (Knowledge ANalyzing

Tracer), a DSL explicitly designed as the front-end

language of APROVER for the speciﬁcation of se-

curity protocols. Kant is a high-level language en-

dowed with primitives for protocol modeling and as-

sumption expression. It has been conceived as a sort

of lingua franca that allows simple textual descrip-

tions to express protocols and easy translation into the

input languages of various tools for protocol analy-

sis. Since Kant has been engineered and developed

by using the Langium platform

, , its grammar deﬁni-

tion comes with an editor and a number of other tools

that allow checking Kant models not only for syntac-

tic correctness, but also for consistency with respect

to a given semantic model. The latter is expressed

in terms of a set of validation rules, which describe

both constraints and best practice principles in design-

ing security protocols. Such a checking mechanism

is extremely important at design-time to avoid com-

mon security errors (e.g., incorrect use of encryption

keys), or to warn the designer regarding choices that

might lead to protocol vulnerabilities (e.g., a princi-

pal’s name not mentioned explicitly in the message).

Note that in Fig. 1 blocks in grey are under devel-

opment and the mapping from Kant to validation and

veriﬁcation tools is out of the scope of this work.

The paper is structured as follows. Section 2 re-

calls the concept of security protocol and presents a

protocol that we use as a reference scenario through-

out the paper. Section 3 introduces the Langium plat-

form used to develop Kant as DSL, while Kant mod-

eling primitives and constructs are given in Section

4. Section 5 presents the semantic model of Kant and

shows the application of the validation rules. In Sec-

tion 6 we show the use of Kant and the language vali-

dation mechanism on the reference scenario. Section

7 compares our results with respect to other research

work in literature, and Section 8 concludes the paper

and outlines future research directions.

2 REFERENCE SCENARIO

Although there is a wide range of protocols, differing

by the number of principals (or actors), the number of

messages, and the goals of the protocol (that may of-

ten be expressed with a list of desired security prop-

erties), they all share a common structure. Indeed,

a communication protocol consists of a sequence of

messages between two or more principals. Each mes-

sage may be written by using the classical Alice&Bob

notation in the form:

M1. A → B : message payload

which speciﬁes:

• The principals (or actors) exchanging messages

(in general, symbols A and B represent arbitrary

principals, S a server). In particular, the direction

of the arrow speciﬁes the sender and the receiver

of the message.

https://langium.org/

Kant: A Domain-Speciﬁc Language for Modeling Security Protocols

• The order in which messages are sent, and their

speciﬁc payload. In particular, M1 is a label iden-

tifying the message, whereas message payload

speciﬁes the actual content of the message.

In secure protocols, payloads can be partially or

totally ciphered, either by symmetric-key encryption

(in this case, a key shared between actors is used both

to encrypt and decrypt), or by asymmetric-key en-

cryption (here, K

and K

-1

is used to specify a pub-

lic and private key of B, to encrypt and, respectively,

decrypt). Message payloads can contain other infor-

mation, such as nonces (N), timestamps (T), etc.

The security goals are often deﬁned with re-

spect to CIA (Conﬁdentiality, Integrity, Authentica-

tion) triad. The most common are conﬁdentiality or

integrity of message payloads, or entity authentica-

tion (i.e., the process by which one entity is assured

of the identity of a second entity that is participating

in the same session of a protocol, thus, they share the

same values of the protocol parameters, such as ses-

sion keys, nonces, etc.).

Consider the classic Needham-Schroeder public-

key protocol (NSPK, for short) that will be used

throughout the paper as a running example to intro-

duce the Kant notation.

M1. A → B : {A, N

}

M2. B → A : {N

, N

}

M3. A → B : {N

}

It was introduced in 1978 for mutual authentica-

tion (here, we omit the exchanges with the certiﬁca-

tion authority to get the public keys). It consists of

three messages: in the ﬁrst message, principal A sends

to B a message containing her identity, A, and a nonce,

, to avoid replay attacks (i.e., reuse of old mes-

sages, often called a challenge message), that only B

can decrypt with his private key. B’s answer (mes-

sage M2) is ciphered with A’s public key and contains

nonce N

to authenticate B (he is the only one able

to decrypt message M1 and obtain N

in clear), and

a nonce N

to authenticate A with B. Since message

M2 is encrypted with A’s public key, she is the only

one who can decrypt it, thus if B receives message M3

containing nonce N

encrypted with his public key, A

is authenticated, too.

3 Kant DEVELOPMENT

Kant (Knowledge ANalysis of Trace) is the domain-

speciﬁc language we explicitly designed and imple-

mented in Langium for the speciﬁcation of security

protocols. Using a tool to engineer a DSL offers sev-

eral advantages that can streamline the development

process and enhance the utility of the DSL, such as

syntax highlighting, autocompletion, and debugging

support.

In particular, Langium represents an innovative

tool in the context of language engineering enabling

DSL development in a web-based technology stack.

When used in the context of a desktop app (e.g.,

VS Code, Eclipse IDE, etc.), Langium runs on the

Node.js platform. Additionally, it can run in a web

browser to add language support to web applications

with embedded text editors (e.g., Monaco Editor).

The interface between Langium and the text editor

is the Language Server Protocol (LSP), allowing lan-

guages based on Langium to seamlessly interact with

a range of popular IDEs and editors supporting LSP.

A grammar language is provided to specify the

syntax and structure of the language. The gram-

mar rules describe the concrete syntax by instructing

the parser how to read input text, and also the ab-

stract syntax in terms of meta-classes and their prop-

erties. For a given text document, Langium creates

a data structure called Abstract Syntax Tree (AST):

every grammar rule invocation leads to a correspond-

ing node in the AST that is a JavaScript object, and

Langium generates a TypeScript interface for every

rule to provide static typing for these nodes. As pro-

grams written in the language are parsed, Langium

automatically generates Abstract Syntax Trees based

on these interfaces, making efﬁcient manipulation and

analysis of the parsed content possible. In particu-

lar, Langium allows to implement also custom vali-

dation without the need to involve complex external

tools, thus ensuring that validation is deﬁned along-

side the grammar speciﬁcation. It provides a cutomiz-

able Validation Registry mapping validation functions

with speciﬁc nodes in the AST, enabling targeted val-

idation checks at relevant points in the AST (e.g., ei-

ther internal or leaf nodes). Designer only need to de-

ﬁne the validation functions encapsulating the desired

checks on both the structural and semantic aspects of

the language captured by the AST, and to update the

Validation Registry with the new functions. This ap-

proach is great for rapid prototyping, when the focus

is on designing the syntax of a new language.

Beyond parsing, Langium extends its capabili-

ties to establish connections between different lan-

guage elements, enabling cross-referencing and link-

ing. These relationships play an important role, and

Langium is capable of resolving them automatically

thanks to built-in scoping and indexing.

Although Langium’s grammar declaration lan-

guage is similar to Xtext, they are built upon different

open-source libraries and tools: Xtext is built upon

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

Eclipse and ANTLR, while Langium is built upon Vi-

sual Code and Chevrotain. Moreover, Xtext is heavily

based on the Eclipse Modeling Framework, whereas

Langium uses TypeScript interfaces, enabling lan-

guage engineering in TypeScript, the same technol-

ogy that is used for VS Code extensions. In con-

trast, building a tool that uses an Xtext-based lan-

guage server with VS Code or Theia means creat-

ing a hybrid technology stack with some parts imple-

mented in Java, others in TypeScript. Development

and maintenance of such a mixed code base are more

demanding, and long-term maintenance is likely more

difﬁcult compared to Langium’s coherent technology

stack.

4 Kant SYNTAX

In this section, we present the abstract and concrete

syntax of the Kant language and we show how it en-

compasses all the essential aspects of security proto-

cols. In particular, it integrates useful features that

can be helpful for the veriﬁcation process and pro-

vide valuable insights for protocol correctness at the

design phase.

The syntax includes constructs of the notations

commonly used to express security protocols (e.g.,

the Alice&Bob notation); however, it has been ex-

tended with the concept of knowledge exchange be-

tween the parties involved in the security protocol ses-

sion to help reasoning and analyzing the ﬂow of infor-

mation during the communication.

Kant has been developed by exploiting the MDE

approach for a DSL deﬁnition, so its abstract syntax is

given in terms of a metamodel from which a concrete

textual notation is derived. Kant’s meta-model (see

Fig. 2) deﬁnes six mandatory meta-classes and two

optional ones, which are necessary to specify a valid

protocol model in Kant. The protocol must contain

speciﬁc elements, including the deﬁnition of princi-

pals involved in the protocol (such as Alice, Bob, and

Server), the types used in the function deﬁnitions and

the deﬁnition of cryptographic functions and their in-

verse functions, the knowledge that each principal has

during the message exchange, and the deﬁnition of the

communication mechanism for messages exchange.

In addition to these mandatory model sections,

two optional meta-classes can be used to deﬁne

shared knowledge between principals, and to help the

user writing, in a human-readable style, either proper-

ties or constraints on the model elements, and security

checks. These statements are arguments for the vali-

dation and veriﬁcation of the model.

Figure 2: Protocol Meta-model.

Principal Deﬁnition. A protocol model (instance

of the meta-model) written in Kant starts with the

name declaration of the principals involved in the

message exchange. Two examples of declarations fol-

low (the user is free to select the most suitable name):

principal Alice

principal Alice, Bob, Server

Type and Function Deﬁnitions. We designed the

language with static analysis in mind, so we included

types it. The user can use built-in types that are de-

clared in the language prelude, but he/she can also

deﬁne other types. An example of type definition

is the following:

type SymmetricKey, PublicKey, BitString, Group

where SymmetricKey and PublicKey are types of

cryptographic keys used for symmetric and asymmet-

ric encryption, respectively; Bitstring is a special

type we call ‘sink type’ since a function that accepts

a Bitstring as a parameter can accept any other type;

Group represents elements of a Abelian group, i.e., a

set of elements with commutative operations.

Types are used to categorize information in the

principal’s knowledge and allow the validation of the

usage of piece of information through the protocol.

Moreover, since some input languages of the back-

end tools are typed, using types at the top-level of

Kant model removes the need for a conversion step.

The FunctionDef meta-class enables users to de-

ﬁne custom functions in agreement with the symbolic

model (Blanchet, 2012) to describe both invertible

and one-way functions. A function is deﬁned by a

Figure 3: Function Deﬁnition Meta-model.

Kant: A Domain-Speciﬁc Language for Modeling Security Protocols

name, one or more parameters, and one or more

return values. Each function component requires

an identifier and a type, either pre-deﬁned or

custom-deﬁned to suit the particular use case. Cryp-

tographic functions, in addition, require the deﬁnition

of a key used to encrypt data (which are the function

parameters).

The separation of the FunctionDef in the com-

posing meta-classes (FunctionParam, Functionkey

and FunctionReturn, see Fig. 3) enables us to de-

ﬁne validation rules (see Section 5) that are speciﬁc

to each class and, in turn, helps to streamline the val-

idation process.

Examples of function deﬁnitions are given below

for the function ENC to encrypt data with a given key

and the one-way cryptographic HASH function.

function ENC(content:BitString)

with k:SymmetricKey -> [ enc:Ciphertext ]

function HASH(value:BitString)

-> [ hash:Digest ] one way

Property Deﬁnition. Properties can be added to

a model to express constraints on model elements

(e.g., on functions and their parameters) or equiva-

lence properties (e.g., Difﬁe-Hellman exponentiation,

as well as other equational theories). For example,

the following property states the identity function as

the result of applying description on encrypted data

by using a symmetric key.

property forall x:BitString, k:SymmetricKey |

DEC(ENC(x) with k) with k -> [ x ]

An example of a property stating function equivalence

is the following that guarantees the Difﬁe-Hellman

equivalence between two private keys a and b on a

generator g in a ﬁnite cyclic group .

property forall a:PrivateKey, b:PrivateKey,

g:Group | DF(EXP(g,b),a)

equals DF(EXP(g,a),b)

Knowledge Deﬁnition. Kant allows declaring the

knowledge of the principals. There are two ways to

accomplish this: (i) at the beginning of the proto-

col model, deﬁne the knowledge that is shared by

selected principals in the initial state of the proto-

col run (by the construct share of the meta-class

SharedKnowledgeDef); (ii) deﬁne private principal’s

According to the Difﬁe-Hellman key exchange proto-

col, the shared secret between two parties is given by the

formula K = (g

)

mod p = (g

)

mod p, being p a prime

number and g a primitive root modulo p on which the two

parties agree and that are public values, a and b secret val-

ues chosen by Alice and Bob, respectively.

Figure 4: Knowledge Meta-model.

knowledge at any point of the protocol model, but

before sending a message (by the construct know in

the meta-class PrincipalKnowledgeDef). In both

cases of knowledge deﬁnition, two qualiﬁers can be

used to distinguish between knowledge that is regen-

erated every time the protocol is executed (fresh

knowledge at any protocol session), and knowledge

that remains the same (constant knowledge dur-

ing a protocol session) – both qualiﬁers are de-

ﬁned in the meta-class KnowledgeDefBuiltin on

top of the meta-classes SharedKnowledgeDef and

PrincipalKnowledgeDef.

Private knowledge of a principal can include the

speciﬁcation of its own Finite State Machine (FSM):

principal’s initial state is speciﬁed as

state initial_state;

at the beginning of the protocol model; information

on a reached state and its enabled transition can be

speciﬁed at any point of the protocol model as:

state reached_state;

transition previous_state

=> reached_state;

Information relative to principal’s FSM is primar-

ily used in veriﬁcation, but it is also useful in valida-

tion to analyze the knowledge ﬂow of principals

Two examples of shared and private knowledge

speciﬁcation follow:

Bob,Alice share{

const key:SymmetricKey;}

Alice know{

state second_state_Alice;

transition first_state_Alice

=> second_state_Alice;

fresh priv_a:PrivateKey;

pub_a = PUB_GEN(priv_a);

enc_mess = ENC(m) with key;}

Since not a mature feature yet, Kant allows for drawing

the FSM of each principal from his/her knowledge block.

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

The knowledge block is used to specify what a

principal knows at the application of a given proto-

col rule. Fig. 4 shows the relation among the meta-

classes for knowledge representation.

Each information is identiﬁed by a reference

priv a of a given type PrivateKey in priv a:-

PrivateKey and can be constant or fresh (from the

meta-class KnowledgeDefBuiltIn). Additionally,

information of meta-class KnowledgeDefCustom is

of the form ref= ... and can refer to the result of

a function application (e.g., puba=PUB GEN(priva)),

or it can reference some saved information de-

rived from the received messages (e.g., dec na =

PKE DEC(enc na)) or built to be sent as a mes-

sage (e.g., enc na = PKE ENC(na)) (see the refer-

ence scenario model, in the following).

Particular importance is given to the two built-in

functions that we have deﬁned to facilitate list man-

agement (and that we use to model our reference sce-

nario). The language prelude contains the basic types

and functions: CONCAT and SPLIT of the meta-class

ListAccess; the former yields the reference of a list

concatenating a sequence of elements; the latter re-

turns the list of elements from a given list reference.

The property that derives from the two functions deﬁ-

nition (see below) guarantees that concatenating a se-

quence of elements into a referenced list and then slit-

ing such referenced list, holds the original list.

function CONCAT(...values: BitString)

-> [ value: BitString ]

function SPLIT(value: BitString)

-> [ values: BitString ]

property forall v: BitString |

SPLIT(CONCAT(...v)) -> [ v ]

Principals Communication. A principal Alice

builds within its knowledge a piece of information,

enc mess, that it wants to send as a protocol message

to one of the other participants, Bob. To send the mes-

sage, we exploit the concrete syntax of the meta-class

CommunicationDef:

Alice->Bob: enc_mess

Security Checks. Kant grammar allows the user to

specify security properties, which are veriﬁed once

the model is transformed into a valid model for the

back-end veriﬁcation tools. The validation rules in-

troduced in Sect. 5 can guarantee a lightweight form

of static analysis of the information ﬂow. Dynamic

analysis can be performed only by back-end veriﬁca-

tion tools.

We provide three meta-classes, Confiden-

tialityCheck, EquivalenceCheck, and Authen-

ticationCheck, to express different kinds of secu-

rity checks. The concrete syntax follows:

• ConﬁdentialityCheck: an information m must be

known only by principals Alice and Bob

only Alice,Bob should know m

• EquivalenceCheck: this is used to check whether

two pieces of information are equal or not; this is

relevant for a security protocol when communica-

tion happens in an insecure channel and some in-

formation can be stolen or altered during the pro-

tocol run.

g_ab, g_ba should be equal

• AuthenticationCheck: the nounce nb allows

Alice to authenticate principal Bob.

Alice should authenticate Bob with nb

Kant Model of the Reference Scenario. The fol-

lowing Kant model

is the speciﬁcation of the NSPK

security protocol described in Sect. 2: Alice and Bob

have an associated FSM; they do not share any knowl-

edge; each principal has private keys, uses a public

key (generated from the corresponding private one)

to encrypt messages, decrypts messages by using its

own private key, generates fresh nonces and builds

private knowledge according to the protocol rules.

principal Alice, Bob

Alice know {

state sending_puba;

const priva: PrivateKey;

puba = PUB_GEN(priva);}

Alice -> Bob : puba

Bob know {

state waiting_puba;

const privb: PrivateKey;

pubb = PUB_GEN(privb);}

Bob -> Alice : pubb

Alice know {

state waiting_pubb;

transition sending_puba=>waiting_pubb;

fresh na: Nonce;

enc_na = PKE_ENC(na) with pubb;}

Alice -> Bob : enc_na

Bob know {

state waiting_enc_na;

transition waiting_puba=>waiting_enc_na;

fresh nb: Nonce;

dec_na = PKE_DEC(enc_na) with privb;

All the Kant language artifacts (grammar, models,

validation rules, etc) are available at https://github.com/

Aprover/kant on GitHub.

Kant: A Domain-Speciﬁc Language for Modeling Security Protocols

nb_na = CONCAT(nb, dec_na);

enc_nb_na = PKE_ENC(nb_na) with puba;}

Bob -> Alice : enc_nb_na

Alice know {

state waiting_enc_na_nb;

transition waiting_pubb =>

waiting_enc_na_nb;

dec_na_nb = PKE_DEC(enc_nb_na) with priva;

rec_na_nb = SPLIT(dec_na_nb);

enc_nb = PKE_ENC(rec_na_nb[1]) with pubb;}

Alice -> Bob : enc_nb

Bob know {

state waiting_enc_nb;

transition waiting_enc_na=>waiting_enc_nb;

dec_nb = PKE_DEC(enc_nb) with privb;}

check nb, dec_nb should be equal

check Bob should authenticate Alice with nb

5 Kant VALIDATION RULES

A model written in a DSL is an instance of the lan-

guage meta-model. Thanks to Langium, a model can

be validated according to certain validation rules and

constraints, covering both syntactic and semantic as-

pects. These rules have to be deﬁned at the meta-

model level. Error and warning messages can be re-

ported upon model validation.

In Kant, the model validation phase helps the pro-

tocol designer to avoid common mistakes such as in-

correct use of encryption keys, or deﬁnition of in-

correct knowledge ﬂows. Moreover, Kant grammar

has some restrictions on the use of undeclared names

of functions, types, and principals, and these restric-

tions are captured by the use of cross-references in

Langium (see Sect. 3). Thus, it is possible to elim-

inate incorrect spelling of terms during model writ-

ing and to suggest, by means of auto-completion, only

what is allowed.

Besides the advantages offered by the cross-

reference mechanism in terms of revealing mistakes

and making suggestions, in order to improve Kant

model validation, we deﬁned and implemented three

sets of validation rules, whose violations result in er-

rors or warnings. Rules for syntactic checks (see Sect.

5.1) are used to reveal syntactic errors that must be

corrected. Rules for semantic checks (see Sect. 5.2)

can reveal potential errors or violations of security

properties. Rules for prudent engineering practices

(see Sect. 5.3) work as guidelines for security pro-

tocol speciﬁcation following some of the principles

outlined in (Abadi and Needham, 1996); they help

to identify and prevent common error patterns found

in the literature, which might lead to attacks. Espe-

Figure 5: Semicolon placement error.

cially for semantic and prudent practice rules, a warn-

ing serves as a suggestion to improve the clarity of

the model, or to adopt good practices in writing the

protocol.

All validations are performed in real-time and are

triggered by the user entering new knowledge. In sec-

tion 5.1.1 we show an example taken from the GUI

of Visual Studio Code, subsequent error reports are

shown in plain text for better readability. We convey

to mark incorrect elements by a red underline, and a

warning by a yellow underline. We use fragments of

the Kant model of the NSPK protocol to show the ap-

plication of the validation rules.

5.1 Syntactic Checks

5.1.1 Syntax Well-Formedness

This set of validation rules checks for the correct

formatting of parentheses, comments, and delimiters

when writing a protocol in Kant. The example in Fig.

5 catches the error of a missing semicolon, which is

used to declare separate knowledge.

5.1.2 Knowledge Declaration

New knowledge must be either fresh, constant or the

result of a function. When declaring fresh or constant

knowledge, the type must also be speciﬁed.

Alice know {

state sending_puba;

const priva;}

The error message speciﬁes the expected token se-

quence:

Expecting: one of these possible token sequences:

1 [ID : [Type:ID]]

2 [ID : [Type:ID], ID : [Type:ID]]

but found: ’priva’.

5.1.3 Naming Convention

The naming convention in Kant requires that princi-

pals’ names start with a capital letter, function names

are capitalized, and variables are in lower case.

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

principal alice , Bob

In this case, it is raised a warning since this is a stylis-

tic convention and not a real error:

Principal name alice should start with a capital letter.

5.1.4 Keyword Usage

Keywords can only be used in the way speciﬁed by the

syntax (similarly to other programming languages).

Bob know {

state state;}

This means that it is not possible to use “state” as a

name for a FSM state. The error produced is:

Expecting token of type ’ID’ but found ‘state‘.

5.1.5 Functions Deﬁnition

A function in Kant is declared as a name, with typed

parameters and typed results. Invocations must follow

the same structure as the deﬁnitions.

function PKE_ENC(content: BitString)

with k: PublicKey -> [pke_enc: Ciphertext]

Alice know {

...

fresh na: Nonce;

fresh nx: Nonce;

enc_na = PKE_ENC(na,nb) with pubb;}

The validator produces the following error because

the declaration has only one parameter:

“PKE ENC” requires “1” argument, but “2” argu-

ments are provided.

A similar error would be produced if the number

of keys entered does not correspond to the number of

keys declared.

5.1.6 Unused Knowledge or Principal

In order to increase the clarity of the model, we warn

the user of all principals and knowledge declarations

that remain unused in the writing of a protocol:

principal Alice, Bob, Server

Principal Server is declared but never used.

5.1.7 Check Fields

User-entered checks in the protocol may only target

knowledge and principals, but not functions.

only Alice,Bob should know CONCAT(na,nb)

Knowledge check should target only knowledge refer-

ences and list access.

5.2 Semantic Checks

5.2.1 Type Compatibility

The types of the parameters used in the function invo-

cation are inferred and checked to be congruent with

those of the declarations.

Bob know {

...

dec_na = PKE_DEC(enc_na) with pubb;

...}

Incorrect key type: “PublicKey”, the invoked function

requires a key of type “PrivateKey”.

5.2.2 Knowledge Scoping

The knowledge declared by a principal is only acces-

sible by that principal or the ones it has shared it with.

Furthermore, the names of new knowledge must be

unique across the entire protocol.

Bob -> Alice : nx

Principal “Bob” doesn’t know “nx”.

5.2.3 Function Inversion

Only functions that are not one way can be inverted

and a property must be speciﬁed for the inversion.

function PKE_ENC(content: BitString)

with k: PublicKey

-> [ pke_enc: Ciphertext ]one way

function PKE_DEC(pke_enc: Ciphertext)

with k: PrivateKey

-> [ content: BitString ]

property forall x: BitString, k: PrivateKey

| PKE_DEC(PKE_ENC(x) with PUB_GEN(k))

with k -> [ x ]

PKE ENC is a one way function, it cannot be in-

verted.

5.2.4 List Access

It is possible to access a list by using only the names

resulting from the application of a SPLIT. The valida-

tion of the SPLIT requires it to be used only on the

results of a CONCAT:

Alice know {

...

dec_na_nb = PKE_DEC(enc_nb_na) with priva;

rec_na_nb = SPLIT(enc_nb_na);

...}

The “SPLIT” function is called on a parameter that

is not the result of “CONCAT”.

Kant: A Domain-Speciﬁc Language for Modeling Security Protocols

5.3 Prudent Engineering Practices

5.3.1 Same Key for Encryption and

Authentication

The usage of the same key for symmetric encryption

and signing can allow an attacker to use the signing

algorithm to decrypt messages, so it is crucial to use

a different key for each method. In this example, Al-

ice uses the same key priva both for decrypting the

message enc bit and to sign the plaintext dec mess.

This causes a potential vulnerability when the signa-

ture is sent out.

Alice know {

fresh bit:BitString;

fresh priva:PrivateKey;

puba = PUB_GEN(priva);}

...

Alice know {

dec_mess = PKE_DEC(enc_bit) with priva;

sign_mess = SIGN(dec_mess) with priva;}

5.3.2 Hash Used as Encryption

A message should not contain a signed hash of a

plaintext as it could have been generated by a third

party and sent to another principal. An example of the

problem can be shown by the example below, which

speciﬁes the following message:

Alice → Bob : {X }

, {HASH(X)}

−1

where {X}

represents the asymmetric encryption of

secret X (in plaintext) using Bob’s public key K

and

{HASH(X)}

−1

represents the signature of the hash

function applied to secret X using Alice’s private key.

Alice know {

enc_x = PKE_ENC(x) with pubb;

hash_x = HASH(x);

sign_hash_x = SIGN(hash_x) with priva;

mess = CONCAT(enc_x,sign_hash_x);}

Alice -> Bob: mess

5.3.3 Encrypt then Sign

The authentication pattern encrypt then sign is vulner-

able to attacks: the attacker can remove the signature

and replace it with its own, claiming ownership of the

message that the recipient receives. Thus, this pat-

tern is generally insecure and should be avoided. To

ensure greater security, it would be better to use the

sign-then-encrypt method and add the identity of the

recipient to the signature. The example below shows

a message mess built by using asymmetric encryp-

tion with a public key pubb. The resulting cyphertext

enc

x is signed and concatenated to the encryption.

Alice know {

enc_x = PKE_ENC(x) with pubb;

sign_enc_x = SIGN(enc_x) with priva;

mess = CONCAT(enc_x,sign_enc_x)}

Alice -> Bob: mess

5.3.4 Add Recipient Identity to Signature

According to (Abadi and Needham, 1996), it is cru-

cial never to infer the principal’s identity from the

content or the sender of a message, as this can lead

to impersonation attacks. To prevent such attacks, it

is essential to mention the identity of the receiver in

the message’s signature. Additionally, although it can

be deduced from the key used to sign the message,

the identity of the sender should also be included. In

the example below, Alice sends a message enc sign

encrypted with asymmetric encryption and containing

a signature sign kab ta that does not include Bob’s

identity.

Alice know {

fresh kab:SymmetricKey;

fresh ta:Nonce;

kab_ta=CONCAT(kab,ta);

sign_kab_ta = SIGN(kab_ta) with priva;

enc_sign = PKE_ENC(sign_kab_ta) with pubb;}

Alice -> Bob: enc_sign

5.3.5 Avoid Double Encryption

Double encryption, also known as cascading encryp-

tion, is a practice that has fallen out of favor in modern

cryptographic security. While it may seem like a log-

ical way to enhance data security, it is often counter-

productive. Double encryption introduces complex-

ity, consumes additional computational resources,

and poses key management challenges. Rather than

enhancing security, it can lead to marginal improve-

ments while increasing the potential for implementa-

tion errors and vulnerabilities. The following example

uses double encryption. The ﬁrst symmetric encryp-

tion with key kab is applied on bit, and the result is

encrypted using public encryption with the key pubb.

Alice know {

fresh bit:BitString;

enc1 = ENC(bit) with kab;

enc2 = PKE_ENC(enc1) with pubb;}

6 Kant EFFECTIVENESS

In order to evaluate the ability of Kant language

to capture the common concepts and primitives

of security protocols, besides the NSPK proto-

col, we modeled classical security protocols such

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

as SSL, Needham-Schroeder, Needham-Schroeder-

Lowe, Woo-lam, Yaholm, BAN-Yaholm, Otway-

Rees, Denning-Sacco, and other protocols are under

development. Kant’s models of all the case studies

have been validated by using the set of validation

rules and, as expected, some warnings were raised on

those protocol aspects that might cause vulnerabilities

– not surprisingly since the rules on prudent engineer-

ing practice (see Sect. 5.3) were deﬁned following the

guidelines suggested in (Abadi and Needham, 1996)

as measures to prevent known attacks against classi-

cal protocols.

Besides modeling constructs in common with

other notations for security protocol description, Kant

has also primitives to model the principal’s knowl-

edge and the FSM of its execution of a given protocol

session. Such concepts are relevant for protocol veri-

ﬁcation by back-end tools, and the advantage of being

already speciﬁed at the level of Kant model facilitates

the translation of these models into models suitable

for veriﬁcation and allows better integration of such

crucial activity into the development process of robust

protocols. Typically, veriﬁcation is undertaken after

the protocol has already been released (Zhang et al.,

2020; Cremers et al., 2016; Lilli et al., 2021), and the

effort of making changes in the protocol is expensive.

Our idea in developing Kant was to facilitate the in-

tegration of veriﬁcation early in the development pro-

cess. In this way, not only one develops consistent

documentation across iterations, but also avoids the

introduction of vulnerabilities when adding new fea-

tures or making changes to cryptographic primitives.

To assess the potentialities of Kant in model-

ing knowledge information ﬂow among parties, we

selected the WPA3 Simultaneous Authentication of

Equals (SAE) protocol

, a password-based authen-

tication and password-authenticated key agreement

method. The choice was due to the fact that this proto-

col includes in its documentation a FSM of the proto-

col instances, and it is one of the ﬁrst protocols to ex-

pose this feature. In addition, it provides advanced se-

curity features such as Forward Secrecy, Eavesdrop-

ping, and Dictionary attack resilience.

The overall picture of the WPA3 SAE protocol

execution is given, in the ofﬁcial documentation, in

terms of the FSM reported in Fig.6. The path in green

describes the transitions performed by each principal

(and are captured by our model) involved in the proto-

col for getting authentication; the other transitions are

performed by other entities described in the WPA3

documentation, and we here abstract from them.

The crucial steps of the protocol message ex-

802.11-2020 - IEEE Standard for Information Tech-

nology

Figure 6: WPA3 SAE FSM.

changes depicted in Fig. 7 are mainly two: (1) the

commitment exchange, to move from state Committed

to state Conﬁrmed, where each party commits to a sin-

gle password guess; (2) the conﬁrmation exchange, to

move from state Conﬁrmed to state Accepted, which

validates the correctness of the guess. The state Noth-

ing is the initial state where a principal is when it is

created and immediately moves to state Committed

when starts the protocol exchange.

The main rules of the protocol are the following:

• A party can commit at any point during the ex-

change.

• Conﬁrmation can only be done after a party and

its peer have committed.

• Authentication is only accepted when a peer has

successfully conﬁrmed.

• The protocol ends successfully when each partic-

ipating party has acknowledged and accepted the

authentication process.

Figure 7: WPA3 SAE key exchange.

The protocol uses modular arithmetic primitives

Kant: A Domain-Speciﬁc Language for Modeling Security Protocols

to calculate numbers sA and sB by summing:

sA = (a + A)modq

sB = (b + B)modq

where a, A, b, B are random numbers, and q is the

(prime) order of the group. Password Equivalent (PE)

is an hashed value of the password that Bob and Alice

know and is raised to the power of −A for Alice and

−B for Bob. Once the commit messages have been

exchanged, the two agents calculate the value k as:

k = (PE

∗ PE

−B

)

= (PE

∗ PE

−A

)

= PE

(1)

The two principals compute KCK as the hash of the

concatenation between k and the sum modulo q of sA

and sB. Finally, they hashed all received information

together with KCK and a counter called send-conﬁrm

(scA, scB) to build the commit messages.

To model in Kant the above computations, we de-

ﬁned the following functions:

function SCALAR_OP(r:Number,y:Group)->[z:Group]

function ELEMENT_OP(x:Group,y:Group)->[z:Group]

function INV_OP(h:Group)->[o:Group]

function SUM_MOD(r:Number,n:Number)->[t:Number]

property forall r:Number, t:Number, p:Group |

ELEMENT_OP(SCALAR_OP(SUM_MOD(r,t),p),

INV_OP(SCALAR_OP(t,p)))-> SCALAR_OP(r,p)

property forall x:Group, y:Group |

ELEMENT_OP(x,y) equals ELEMENT_OP(y,x)

property forall r:Number, t:Number |

SUM_MOD(r,t) equals SUM_MOD(t,r)

In both Finite Field Cryptography (FFC) and El-

liptic curve cryptography (ECC) groups, WAP3 SAE

employs three arithmetic operators: the element func-

tion ELEMENT OP that produces a group from two

groups, the scalar function SCALAR OP that generates

a group from an integer and a group, and the inverse

function INV OP that produces a group from a group.

The protocol uses modular arithmetic, we added the

function SUM MOD has been added for this purpose

(we omit the module as argument since it is of pub-

lic domain and not relevant for the analysis). We then

added various properties to address the commutativity

of functions ELEMENT OP and SUM MOD, and a property

that allows us to perform the mathematical simpliﬁca-

tion as described in the Formula 1.

The model of the WPA3 protocol in Kant, upon

checking syntactic and semantic validation rules, is

available at WPA3 SAE. This case study shows the

expressive potential of the language in modeling a

protocol having very high mathematical complexity.

Moreover, thanks to the capability to express state end

transition in the knowledge of a principal, the model

is able to reﬂect the structure of the FSM in Fig. 6.

7 RELATED WORK

Formal veriﬁcation of security protocols has been a

critical area of research and development in computer

security in the last twenty years. Many techniques

and tools have been proposed for verifying protocols.

Depending on the speciﬁc tool, either the protocol has

been translated into the tool input language, or a new

language has been deﬁned to model the protocol. In

most of the cases, the language was not user-friendly,

requiring expertise in formal methods and protocol

analysis. There are indeed some examples of domain-

speciﬁc languages that inspired us when deciding

which features needed to be included in the language,

such as the knowledge notion, or the state. For exam-

ple, in the seminal paper (Burrows et al., 1990) intro-

ducing one of the ﬁrst formalisms designed to reason

about protocols, the authors recognize the importance

of make explicit the assumptions (called principal’s

beliefs and assumptions) taken before the execution

of the protocol, which we expressed with the princi-

pal’s knowledge.

AVISPA (Automated Validation of Internet Se-

curity Protocols and Applications) (Armando et al.,

2005) supports the editing of protocol speciﬁcations

and allows the user to select and conﬁgure the differ-

ent back-ends of the tool, similarly to our long-term

goal. The protocol is given in the High-Level Proto-

col Speciﬁcation Language HLPSL (Chevalier et al.,

2004), an expressive, modular, role-based, formal lan-

guage, thus not really user-friendly; HLPSL speciﬁ-

cations are then translated to the so-called Interme-

diate Format (IF), an even more mathematical-based

language at an accordingly lower abstraction level and

is thus more suitable for automated deduction.

Also Sapic+ (Cheval et al., 2022) aims at exploit-

ing the strengths of some of the tools that reached

a high degree of maturity in the last decades, e.g.,

TAMARIN and PROVERIF, offering a protocol veriﬁ-

cation platform that permits choosing the tool. How-

ever, the input language is an applied π calculus sim-

ilar to PROVERIF, thus it requires high expertise in

equational theories and rewrite systems.

In (Jacquemard et al., 2000; M

odersheim, 2009),

the authors deﬁne and give the semantics of AnB,

a formal protocol description language based on the

classical Alice&Bob notation we introduced in Sect.

2. However, in the translation, part of the readability

is lost since a mathematical notation is used.

The work most related to ours is Verifpal (Cheva-

lier et al., 2004), which uses a user-friendly high-level

language that allows users to model cryptographic

protocols and security properties in a rather intuitive

way. The tool uses symbolic analysis techniques, and

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

can automatically generate formal veriﬁcation code

in the TAMARIN prover’s input language, making it

compatible with TAMARIN for further in-depth anal-

ysis and veriﬁcation. However, they provide only a

text editor with a syntax highlighter, whereas in our

case we do both syntax and semantic checking.

8 CONCLUSIONS

We presented Kant (Knowledge ANalysis of Trace),

a DSL we explicitly designed and developed in

Langium for the speciﬁcation of security protocols.

Kant has been conceived as a front-end and easy-to-

use language of a formal framework under develop-

ment to support different back-end tools for security

protocol analysis. The Kant grammar encompasses

constructs of the notations commonly used to express

security protocols, but it also has primitives to model

information that is fundamental for formal analysis

(done by back-end tools), i.e., (1) the knowledge ﬂow

exchanged between the parties during a protocol ses-

sion, and (2) the FSM model that is behind the ex-

ecution of each participant. A further innovative fea-

ture of Kant w.r.t. other notations for security protocol

modeling is its embedded mechanism of model vali-

dation against a set of validation rules, which helps

the designer avoid common security errors or make

design choices leading to protocol vulnerabilities.

In future work, our ﬁrst goal is to automate

the transformation of a Kant model in input mod-

els of the back-end tools (ASMETA, TAMARIN, and

PROVERIF are the ﬁrst choices, see Fig. 1) by exploit-

ing the advantages of the Model-driven Language De-

velopment. We also plan to develop a graphical front-

end for APROVER for a visual rendering of Kant

models.

REFERENCES

Abadi, M. and Needham, R. (1996). Prudent engineering

practice for cryptographic protocols. IEEE Transac-

tions on Software Engineering, 22(1):6–15.

Anderson, R. and Needham, R. (1995). Programming Sa-

tan’s computer, pages 426–440. Springer Berlin Hei-

delberg, Berlin, Heidelberg.

Arcaini, P., Gargantini, A., Riccobene, E., and Scandurra,

P. (2011). A model-driven process for engineering a

toolset for a formal method. Software: Practice and

Experience, 41(2):155–166.

Armando, A., Basin, D., Boichut, Y., Chevalier, Y., Com-

pagna, L., Cuellar, J., Drielsma, P. H., He

am, P. C.,

Kouchnarenko, O., Mantovani, J., M

odersheim, S.,

von Oheimb, D., Rusinowitch, M., Santiago, J., Tu-

ruani, M., Vigan

o, L., and Vigneron, L. (2005). The

AVISPA Tool for the Automated Validation of Inter-

net Security Protocols and Applications. In Computer

Aided Veriﬁcation (CAV’05), pages 281–285.

Basin, D., Dreier, J., Hirschi, L., Radomirovic, S., Sasse, R.,

and Stettler, V. (2018). A Formal Analysis of 5G Au-

thentication. In Proc. of the ACM SIGSAC Conf. on

Computer and Communications Security (CCS’18),

pages 1383–1396.

Blanchet, B. (2001). An efﬁcient cryptographic protocol

veriﬁer based on prolog rules. In Proc. of IEEE Com-

puter Security Foundations Workshop, pages 82–96.

Blanchet, B. (2012). Security Protocol Veriﬁcation: Sym-

bolic and Computational Models. In Principles of Se-

curity and Trust, pages 3–29.

Burrows, M., Abadi, M., and Needham, R. (1990). A

Logic of Authentication. ACM Trans. Comput. Syst.,

8(1):18–36.

Cheval, V., Jacomme, C., Kremer, S., and K

unnemann, R.

(2022). Sapic+: protocol veriﬁers of the world, unite!

Cryptology ePrint Archive, Paper 2022/741. https://

eprint.iacr.org/2022/741.

Chevalier, Y., Compagna, L., Cuellar, J., Drielsma, P. H.,

Mantovani, J., M

odersheim, S., and Vigneron, L.

(2004). A High Level Protocol Speciﬁcation Lan-

guage for Industrial Security-Sensitive Protocols. In

Workshop on Speciﬁcation and Automated Processing

of Security Requirements (SAPS’04).

Cremers, C., Horvat, M., Scott, S., and van der Merwe, T.

(2016). Automated analysis and veriﬁcation of tls 1.3:

0-rtt, resumption and delayed authentication. In 2016

IEEE Symposium on Security and Privacy (SP), pages

470–485.

Davis, J., Clark, M., Cofer, D., and et al. (2013). Study on

the barriers to the industrial adoption of formal meth-

ods. LNCS, 8187:63–77.

Haskins, B., Stecklein, J., Dick, B., Moroney, G., Lovell,

R., and Dabney, J. (2004). 8.4.2 Error Cost Escala-

tion Through the Project Life Cycle. INCOSE Inter-

national Symposium, 14:1723–1737.

Heinrich, R., Bousse, E., Koch, S., Rensink, A., Riccobene,

E., Ratiu, D., and Sirjani, M. (2021). Integration and

orchestration of analysis tools. In Composing Model-

Based Analysis Tools, pages 71–95.

Jacquemard, F., Rusinowitch, M., and Vigneron, L. (2000).

Compiling and Verifying Security Protocols. In Logic

for Programming and Automated Reasoning, pages

131–160.

Lilli, M., Braghin, C., and Riccobene, E. (2021). Formal

Proof of a Vulnerability in Z-Wave IoT Protocol. In

Int. Conf. on Security and Cryptography.

Meier, S., Schmidt, B., Cremers, C., and Basin, D. (2013).

The TAMARIN Prover for the Symbolic Analysis of

Security Protocols. In Computer Aided Veriﬁcation

(CAV’13), pages 696–701.

odersheim, S. (2009). Algebraic Properties in Alice and

Bob Notation. In Int. Conf. on Availability, Reliability

and Security, pages 433–440.

Tobarra, L., Cazorla, D., Pardo, J. J., and Cuartero, F.

(2008). Formal Veriﬁcation of the Secure Sockets

Layer Protocol. In - Proc. of the Int. Conf. on En-

terprise Information Systems (ICEIS’08), pages 246–

252.

Zhang, J., Yang, L., Cao, W., and Wang, Q. (2020). IEEE

Access, 8:23674–23688.

Kant: A Domain-Speciﬁc Language for Modeling Security Protocols