Security Protocol Deployment Risk
Simon N. Foley
1
, Giampaolo Bella
2,3
, and Stefano Bistarelli
4,5
1
Department of Computer Science, University College Cork, Ireland
2
SAP Research, Mougins, France
3
Dipartimento di Matematica e Informatica, Universit`a di Catania, Italy
4
Dipartimento di Scienze, U niversit´a degli Studi “G. D’Annunzio”, Pescara, Italy
5
Istituto di Informatica e Telematica, CNR, Pisa, Italy
Security protocol participants are software and/or hardware agents that
are—as with any system—potentially vulnerable to failure. Protocol analysis
should extend not just to an analysis of the protocol specification, but also to
its implementation and configuration in its target environment. However, an
in-depth formal analysis that considers the behavior and interaction of all com-
ponents in their environment is not feasible in practice.
This paper considers the analysis of protocol deployment rather than imple-
mentation. Instead of co nce ntrating on detailed semantics and formal verification
of the protocol and implementation, we are concerned more with with the a bil-
ity to trace, at a practical level of abstraction, how the protocol deployment,
that is, the configuration of the protocol components , relate to each other and
the overall protocol goals. We believe that a co mplete security verification of a
system is not c urrently achievable in practice and seek some degree of useful
feedback from an analysis that a particular protocol deployment is reasonable.
1 Vulnerabilities in Deployed Protocols
The deployment of a protocol is a collection of interacting software/hardware
components that collectively implement the protocol in its environment. Compo-
nents range from agents that fully implement a protocol principal, for example,
an authentication server running on a bastion host, to entities that pa rtially
support the principal, for example, a hardware toke n authenticator. These co m-
ponents may suffer a variety of vulnerabilities.
Design Vulnerabilities are errors in the underlying desig n of the protocol whereby
it fails to achieve its intended security goals. For e xample, a replay attack on the
protocol that e nables a principal to masquerade as a different principa l [2, 5].
Implementation Vulnerabilities The software that implements the protoco l may
be vulnerable to attack. For example, a component with a buffer-overflow vul-
nerability may be vulnerable to a stack-smashing attack from another principal
that could lead to, for example, disclosure of keys, replay attack, etc. Improper
implementation of a client may also facilitate an attack, for example, a Ker-
beros client that does not disc ard the user-password (long-term key) once the
ticket-granting ticket/key is obtained from the authentication server.
Configuration Vulnerabilities are a consequence of any improper configuration
of the component that might lead to its compromise. For example, an authenti-
cation server that stores long-term cleartext keys in a file that is acc essible by all
users. An authentication client that incorporates a hardware token authenticator
might be cons idered less vulnerable than a client that relied on a fix e d password
for its long-term se c ret.
System Vulnerabilities The platform that hos ts a component may itself be v ul-
nerable to attack. For example, deploying an authentication server on a system
alongside a web-server would be cons idered a poor choice. Similarly, hosting an
authentication server on a hardened bastion host managed by a competent ad-
ministrator might be consider e d less vulnerable to attack than hosting it on an
out-of-the-box workstation that ha s outstanding software patches.
There are many further vulnerabilities that co uld be considered, for example,
cryptographic API vulnerabilities, vulnerabilities in weak cryptog raphic opera-
tions, and so forth. We do no t intend to analyz e or model vulnerabilities per-se,
but instead reflect vulnerability and threat in terms of an abstract degree of
confidence that we have in a component’s secure and proper operation. The de-
gree of confidence of a component can be based on evidence (a ‘correct’ protocol
running on a bastio n host) and/or subjective views (the administrator of this
system is considere d to be incompetent). We do not intend to only consider
the deployment of components for which we have complete competence: we are
interested in determining whether protocols that are deployed as combinations
of good, bad and indifferent components are good enough.
2 Protocol Deployment Risk
Degree of confidence [6] is defined in terms of the set C of co nfidence levels that
is ordered under ≤. This is interpreted as: given a , b ∈ C then a ≤ b means
that we have no less confidence in a component with confidence level b than
a component with confidence level a. For example, we might define confidence
levels lo < med < hi, with the obvious inte rpretation, for example, we have lo
confidence in a component executing on an open-access workstation and have hi
confidence in an authentication server executing on a bas tion host. In this paper
a c-semiring [3 ] is used to represent degre e o f confidence. This provides a variety
of measures for confidence, ranging from simple orderings such as lo < med < hi
to numeric measures such as fuzzy and numeric weightings.
We consider confidence in the context of the cryptographic keys that the
protocol components are expected to manage. For example, we might have a
high degree of confidence that an authentication server component, with few
known vulnerabilities, properly secures the keys that it manages; this might
reflect a c onfidence that it will not leak keys to the public channel.
Another ordering ≤ is defined over the class of cryptographic keys r e ferenced
in the protocol to reflect the degree to which they require protection [1]. For ex-
ample, a long-term password would be considered mor e critical than a short-term
session ke y, since compromise of the latter is a once-off threat, while compromise
of the former may lead to repeated attacks. The set K of ke y classifications forms
a lattice under ≤ with a lower bound element public that represents the public
channel.
Example 1 An authentication and key distribution server Trent manages long
term and session keys. Trent shares long term keys with principals Alice and
Bob, and issues shor t- term session keys. The following Needham-Schroder style
protocol is followe d to acheive key exchange. For the moment we do not consider
the components that Alice, Bob or Trent might comprise.
Msg 1 : A → T : A, B, N
A
Msg 2 : T → A : {|K
AB
, A, B, N
A
, T
T
|}
K
A
, {|K
AB
, A, B, T
T
|}
K
B
Msg 3 : A → B : {|K
AB
, A, B, T
T
|}
K
B
Three symmetric keys K
A
, K
B
and K
AB
are used in this protocol, and we define
corresponding key classes levels Ka, Kb and Kab; class public corresponds to the
public channel.
Figure 1 defines the class ordering (K, ≤ ). Long-term keys are used to tr ansfer
session keys and, therefore, we have Kab < Ka a nd Kab < Kb where Ka and Kb
are disjoint (cannot deduce one from the other), and ⊤ defines the universal
upper bound on the ordering. This reflects an assumption in the protocol that
long-term keys are considered more security-critical than session keys: in the
absence of ephemera l keys, loss of the long-term key implies loss of the sho rt-
term keys (but not vice-versa). △
Ka Kb
Kab
⊤
public
Fig. 1. Key Classification Ordering (K, ≤)
The key classification order ing defines the flow constraints between keys, for
example, long term key Ka information should not be permitted to flow to session
key Kab information. Rather than relying on a binary interpretation of how key
related information may/may not flow, we take a qualitative-based approach
that is similar to the notion of assurance in [9, 7]. Define
minConf : K × K → C
where minConf (k, k
′
) defines the minimum confidence r e quired across the pro-
tocol deployment that a ke y of class k does not flow to class k
′
. The lower bound
⊥ in the confidence c-semiring is interpreted as no flow restriction and thus, if
k ≤ k
′
, then minConf(k, k
′
) = ⊥ in the confidence c -semiring, since, in this
case, the flow is permitted.
Example 2 Cons ider the set (C, ≤) of c onfidence ratings nil < lo < med < hi,
where nil is the lower bound and corresponds to no flow restriction. Given the
protocol in Example 1 then there are no flow res trictions on public as a source,
that is, minConf (public, x) = nil fo r a ny x ∈ K. By reflexivity of (K, ≤) we also
have minConf (x, x) = nil for x ∈ K.
Key class ⊤ represents the most security-critical key (a ggregate of the long-
term keys) and we define:
minConf([⊤, public]) = hi
minConf([⊤, Kab]) = hi
minConf([⊤, Ka]) = med
minConf([⊤, Kb]) = med
An a uthorization server that manages both long -term keys and the session key
(interval [Kab, ⊤] requires greater confidence (hi) in its protection than its clients
(confidence med) that manage one long-term key and session key; in the former,
we r e quire greater confidence that the keys cannot be leaked. We have:
minConf([Ka, Kab]) = med
minConf([Ka, Kb]) = hi
minConf([Ka, public]) = med
minConf([Ka, ⊤]) = nil
with a similar definition for Kb. Protecting only a session key requires less con-
fidence:
minConf([Kab, public]) = lo
minConf([Kab, Ka]) = nil
minConf([Kab, Kb]) = nil minConf([Kab, ⊤]) = nil
△
Each protocol component can be regarded as managing a number of differe nt
kinds of keys. The authentication server in Example 1 manages Ka, Kb and Kab
key and the client manages Kab and Ka keys. Every c omponent c, is bound to
an interval of the key classification lattice, where int(c) = [l, h] ∈ K × K, and
l ≤ h is interpreted as follows:
– l is the lowest classifica tion key that the component encrypts messa ges with.
Here encr ypt is like ’send’ in terms of infor mation flow between key classifi-
cations.
– h is the highest classification key that the component decrypts messa ges
with. Here decrypt is like ’rec e ive’ in terms of information flow between key
classifications.
We also write int(c) = [int
⊥
(c), int
⊤
(c)].
Each protocol component c also has a confidence rating given as rating(c)
that also reflects the minimum effort that would be required by an attacker to
compromise component c. For example, we might have high confidence in the a u-
thenticatio n servic e in Example 1 that is deployed on a hardened selinux server,
but have low confidence in the client component implemented as freeware and
running on an open-access workstation. In the case of the a uthentication server
we are confident that keys will not be leaked nor messages encrypted/decrypted
in a way that does not follow the protocol specification. This c onfidence comes
from a belief that the protocol is properly implemented and that it is unlikely
that the hosting server ca n be compromised. On the other hand, and in the
absense of further information, our degree of confidence that an open-access
workstation running freeware follows the protocol and/or cannot be co mpro-
mised, is low as it may be subject to a variety of attacks ranging from Trojan
Horses in the protocol implementation to vulnerabilities such as buffer overflows
in the underlying system.
Example 3 The components in Example 1 are defined with the following in-
tervals.
c int(c) rating(c)
A [public, Ka] med
B [Kab, Kb] med
T [Kab, ⊤] hi
Principal A manages keys in the ra nge [public, Ka], reflecting that it sends/encrypts
data on the public channel and decrypts/receives up to Ka class information. Note
that in this deployment we assume that principals B and T do not write to the
public channel.
The table also provides sample confidence rating for principals. We have
medium confidence that principal B pro perly protects its key information in the
range [Kab, Kb]—this assumes that B doe s not access to the public channel—
perhaps B is known to be confined to a protection domain which does not give it
direct access to the public channel. In practice, the ra ting of a component should
depend on the keys it protects: we might have a high degree of confidence that
B does not write Kb information to the public channel while have a medium
degree of confidence that it does not write Kb to Kab. Fo r the sake of simplicity
in this paper we restrict ourselves to the interpretation of the rating function
as a property of the component that is independent of the keys it manages. △
Definition 1 Each protocol component must meet the minimum re quired con-
fidence, that is, for every component c then
∀x, y : K | int
⊥
(c) ≤ x ≤ int
⊤
(c) ∧ int
⊥
(c) ≤ y ≤ int
⊤
(c)
⇒ minConf(x, y) ≤ r ating(c)
that is, the component achieves the required degree of confidence for every pa ir
of keys that it manages. △
When a deployed protocol executes, there is a resulting flow of messages
betwee n compo nents. Let A
x
; B
y
represent a flow o f a message encrypted using
an x-level key by A and decr ypted using a y-level key by B.
