level specification languages into ASLan and from
ASLan back to the high-level specification language
used for the new service specified. The following con-
nectors are available:
1. ASLan++ connector - provides translation be-
tween ASLan and ASLan++, which has been
designed specifying dynamically composed
security-sensitive web services and service-
oriented architectures (Oheimb and Modersheim,
2011).
2. AnB connector is used in case one prefers ex-
tended Alice-and-Bob notation or message se-
quence charts.
3. HLPLS++ connector translates the HLPSL mod-
els (Yannick Chevalier, 2004) and can easily be
used by protocol engineers/designers.
4. BPMN + Annotations connector is responsible for
the translation of business process standard lan-
guages used by practitioners in the field. This
avoid forcing the business process practitioners to
model the protocol twice.
The Orchestrator receives the input from the con-
nector layer and uses automated reasoning techniques
to produce a specification of the target service that is
guaranteed to satisfy the specified goals. If the output
specification does not meet the security requirements,
the validator returns a counter-example to the orches-
trator, which generates another target service specifi-
cation.
The Validator is responsible checking the Orches-
trator output. If the orchestration meets the security
requirements, the Validator outputs the service spec-
ification to the Connectors layer. Otherwise, it pro-
vides to the Orchestrator a counter-example which is
used to generate another orchestration.
Using AVANTSSAR as presented in (Alessan-
dro Armando, 2008), Alessandro Armando et al. were
able to model SAML-based SSO (Single Sign On)
protocol used by Google Applications. They discov-
ered a severe security flaw that was unknown at that
time and that allowed a dishonest service provider to
impersonate a user at another service provider. The
attack was reproduced in the actual deployment of
Google Application.
3 AVISPA VS. AVANTSSAR
For the comparison, the AVISPA and AVANTSSAR
platform validators were run for 29 of the most known
security protocols to analyze the performance of the
verification. The following data was considered: the
running time of the validators for each security pro-
tocol and the number of attacks found. All valida-
tors provide statistics on the states and transitions an-
alyzed, as well as the running time. When comparing
the performance, the criteria has been the total time
taken by each validator to check all the 29 protocols
(the sum of the times for each protocol).
Table 1: CL-Atse Run Time.
Protocol CL-Atse - AVISPA CL-Atse AVANTSSAR
A T1 T2 T3 Tm A T1 T2 T3 Tm
AAAMobileIP NO 0.0 0.0 0.0 0.0 NO 0.1 0.08 0.09 0.09
CHAPv2 NO 0.0 0.0 0.0 0.0 NO 0.04 0.04 0.05 0.043
CRAM-MD5 NO 0.02 0.02 0.02 0.02 NO 0.31 0.33 0.32 0.32
DHCP-delayed-auth NO 0.0 0.0 0.0 0.0 NO 0.01 0.007 0.008 0.0083
EKE YES 0.0 0.0 0.0 0.0 YES 0.06 0.067 0.075 0.0673
EKE2 NO 0.0 0.0 0.0 0.0 NO 0.02 0.022 0.024 0.022
h.530 OUT OF MEMORY NO 0.08 0.11 0.091 0.093
h.530-fix OUT OF MEMORY NO 0.11 0.1 0.14 0.116
IKEv2-CHILD NO 0.02 0.02 0.02 0.02 NO 6.2 6.1 7.7 6.6
IKEv2-DS YES 0.0 0.0 0.0 0.0 YES 0.03 0.045 0.046 0.04
IKEv2-DSx NO 5.16 5.14 5.2 5.16 NO 112 117 122 117
IKEv2-MAC NO 0.0 0.0 0.2 0.06 NO 1.45 1.46 1.16 1.356
IKEv2-MACx NO 3.36 3.4 3.32 3.36 NO 61 73 71 68.3
ISO1 YES 0.0 0.0 0.0 0.0 YES 0.005 0.006 0.005 0.0053
ISO2 NO 0.0 0.0 0.0 0.0 NO 0.011 0.01 0.01 0.0103
ISO3 YES 0.0 0.0 0.0 0.0 YES 0.016 0.016 0.016 0.016
ISO4 NO 0.0 0.0 0.0 0.0 NO 0.32 0.31 0.3 0.31
Kerb-basic NO 0.02 0.02 0.0 0.013 NO 6.58 6.42 6.52 6.506
Kerb-Cross-Realm NO 0.04 0.06 0.04 0.046 NO 755 721 695 723.6
Kerb-Forwardable NO 0.06 0.04 0.02 0.04 NO 23.2 22.8 22.6 22.8
LPD-IMSR NO 0.0 0.0 0.0 0.0 NO 0.012 0.012 0.011 0.0116
LPD-MSR YES 0.0 0.0 0.0 0.0 YES 0.007 0.006 0.007 0.006
PBK YES 0.0 0.0 0.0 0.0 YES 0.016 0.015 0.014 0.014
PBK-fix YES 0.0 0.0 0.0 0.0 YES 0.016 0.017 0.018 0.017
PBK-fix-weak-auth NO 0.06 0.04 0.06 0.053 NO 26.15 26.09 26.18 26.14
SPEKE NO 0.02 0.02 0.02 0.02 NO 0.157 0.161 0.159 0.159
SRP NO 0.0 0.0 0.0 0.0 NO 0.036 0.035 0.028 0.033
TLS NO 0.0 0.02 0.0 0.006 NO 0.11 0.105 0.108 0.107
UMTS AKA NO 0.0 0.0 0.0 0.0 - - - - -
Total time (s) 8.798 8827.929
The tests were performed on a computer with In-
tel Core i7-4510U processor, 4 GB of RAM, and an
Ubuntu 14.04 operating system.
Each tool was used to check the following secu-
rity properties of the selected protocols: secrecy and
authentication. Secrecy can be modeled in each of
the considered instruments. Authentication cannot be
modeled by TA4SP. For the analysis of the obtained
results, it is worth to take into consideration the fol-
lowing point: SATMC provides a number of features
(e.g. model checking of LTL properties (Armando
and Compagna, 2016)) that are not supported by CL-
AtSe and OFMC and that are not used in the consid-
ered benchmark protocols.
The results obtained are found in Tables 1, 2 and
3, where column A specifies whether a protocol at-
tack has been found, columns T1, T2, T3 represent 3
validator runtimes, and the Tm column represents the
average running time. The result of the verification
of certain protocols was declared inconclusive by the
validator, not specifying whether or not an attack was
found. The last line for each table highlights the total
running time of the back-ends for the verification of
all 29 protocols. Thus is simple to see which one has
the best overall performance.
Validators versions used by AVISPA are as fol-
lows: CL-Atse - version 2.2-5, OFMC - version
of 2006/02/13 (version number is not available),
SATMC - version 2.1, TA4SP - version of AVISPA-
1.1 (version number is not available).
The same protocols have been verified with the
SECRYPT 2018 - International Conference on Security and Cryptography
522