The Journal of Systems and Software 82 (2009) 101111

Contents lists available at ScienceDirect

The Journal of Systems and Software

journal homepage: www.elsevier.com/locate/jss

A security policy language for wireless sensor networks

David W. Marsh a, Rusty O. Baldwin a,*, Barry E. Mullins a, Robert F. Mills a, Michael R. Grimaila b
a b

Department of Electrical and Computer Engineering, Air Force Institute of Technology, 2950 Hobson Way, OH 45433, USA Department of Systems and Engineering Management, Air Force Institute of Technology, USA

a r t i c l e

i n f o

a b s t r a c t
Authenticated computer system users are only authorized to access certain data within the system. In the future, wireless sensor networks (WSNs) will need to restrict access to data as well. To date, WSN security has largely been based on encryption and authentication schemes. The WSN Authorization Specication Language (WASL) is a mechanism-independent composable WSN policy language that can specify arbitrary and composable security policies that are able to span and integrate multiple WSN policies. Using WASL, a multi-level security policy for a 1000 node network requires only 60 bytes of memory per node. Published by Elsevier Inc.

Article history: Received 11 January 2008 Received in revised form 16 April 2008 Accepted 12 May 2008 Available online 20 May 2008 Keywords: Wireless sensor network Data security Security policy Security policy composition

1. Introduction Because of advancements in micro-electro-mechanical systems, wireless sensor network (WSN) nodes can now be made smaller than their power sources. Improvements in computing and wireless networking technologies will provide access to the sensors data at a level heretofore unattainable. We envision a future with WSNs composed of nano-sensors embedded within, say, building materials to provide data on the condition of the material or environment around it. While it is not the case with WSNs currently, we maintain that data within a WSN should have (and indeed will soon be required to have) the same level of data protection as that found in modern computer operating systems. Furthermore, it can reasonably be expected that WSNs with distinct security policies will eventually be required to interact with each other while maintaining their respective security policies. Therefore, policy composition must be supported by WSN security policies too. Some research and development has focused on restricting WSN resources to authorized users via authentication protocols (Perrig et al., 2001; Di Pietro et al., 2003; Benenson et al., 2005). Particular access control schemes have also been proposed including (Donggang, 2007; Wang and Li, 2006; Zhou et al., 2007). Encryption has been used to enforce condentiality and to restrict computing resources to authorized entities (Oliveira et al., 2007; Karlof et al., 2004; Gaubatz et al., 2005). Encryption and authentication are well-established techniques that address particular aspects of security; they are essential but incomplete elements of security in a WSN. Encryption will indeed protect the condential* Corresponding author. Tel.: +1 937 255 6565. E-mail address: rusty.baldwin@at.edu (R.O. Baldwin). 0164-1212/$ - see front matter Published by Elsevier Inc. doi:10.1016/j.jss.2008.05.010

ity of WSN data during transmission while authentication will prevent unauthorized users from accessing a WSN. Even so, we rightly expect that even authorized users of computer systems will not have access to all the data on the system. That is, we expect our les and data to remain condential even from other authorized users of the system. As WSNs become more commonplace, the same will be expected of them. WSN nodes, however, have severe limits on processing power, memory, wireless communication capabilities, and energy stores (Zhao and Guibas, 2004). The MICA2 Mote (Crossbow, 2007), for example, weighs 18 g and operates on two AA batteries. It hosts the TinyOS operating system on an ATmega128L 8 bit processor running at 8 MHz with 4 kB RAM and 128 kB ash RAM for code. Therefore, any practical security scheme will have to take this into account. We see this severely resource-constrained environment as a persistent characteristic of current WSN nodes as well as the micro- or nano-scale nodes of the future. Security policies are generally represented by sets of rules. Given a request for some action, a servicing agent evaluates these rules according to the current status of the system and relevant information about the query. The information required by the agent to make a decision can be quite largeall the user identications and groupings, object identities and groupings, associations of users and objects with security levels, mandatory authorizations and discretionary rules and explicit authorizations, and information about the history of actions performed in the system. Signicant processing power and memory may be required to evaluate a number of rules against all the variables. Alternatively, memory could be saved by requiring that relevant associations (e.g., user groupings) be sent with a query, adding to the data required during query transmission.

102

D.W. Marsh et al. / The Journal of Systems and Software 82 (2009) 101111

With these considerations in mind, we propose a mechanismindependent composable WSN policy language called the WSN Authorization Specication Language (WASL). The resulting system distributes only system authorizations to nodes, reducing both the memory and computational requirements at the nodes. WASL is based on the Authorization Specication Language (ASL) (Jajodia et al., 1997) that provides a formal basis for specifying security policies, capturing policy authorizations, and describing the environments in which the policies function. WSN-specic modications to ASL adapts it to a wireless environment. WASL, in conjunction with existing encryption and authentication mechanisms, constitute a robust system that will prevent, per the specied policy, unauthorized access to WSN resources. Although security policies, not mechanisms, are the focus of this research, we also present a simple implementation scheme to demonstrate that our system can be reasonably implemented within the constraints of a WSN node. The remainder of this paper is organized as follows: Section 2 introduces the notion of security used in this work. The key contribution is the language WASL, as presented in Section 3 followed by implementation considerations made Section 4. Section 5 presents results of composition and compilation of WASL-encoded policies.

2. Background This section provides a brief overview of security elements, security policies, and policy composition. Security is often dened in terms of three properties: integrity, availability, and condentiality. Integrity pertains to the trustworthiness of data and can be formally expressed using Bibas Model (Biba, 1977). Availability is the ability of a user to access data on demand. Condentiality ensures restricted data remain hidden from unauthorized users. Condentiality is dened using the BellLaPadula (BLP) Model that identies the appropriate interaction of users (the entities acting within a system) and objects (the objects acted upon in a system). In a BLP-Modeled system there are two or more security levels organized in a hierarchy requiring that each level either be higher or lower than each of the other levels. Every user and object is associated with one security level. Protection of high objects requires that no low subjects have read access. Similarly, high subjects are not permitted to write to low objects lest protected information be transmitted to a lesser-protected domain. Informally, BLP requirements can be summed up by the phrase, Reads up and writes down are not allowed. The BLP Model also introduces the concepts of mandatory access controls (MACs) and discretionary access controls (DACs). MACs enforce the reads up and writes down restrictions; they are strictly enforced as any violation would nullify the security model. DACs, on the other hand, are set at the discretion of the owner of an object. Discretionary controls cannot override accesses prohibited by the MACs. While an individual systems security can be dened using security policies, few computer networks operate in isolation from other networks. Policy composition enables the interaction of subjects under one policy with objects under another. The policy composition framework in (Bonatti et al., 2002) describes an algebra by which heterogeneous policies can be integrated while maintaining their independence. The composition algebra provides a variety of operators for manipulating policies but, as is presented in Section 3.6, only two are necessary for the scheme developed herein. 3. WSN Authorization Specication Language To implement a policy-enforcement system we must rst have a policy specication language. This language should be exible

enough to express a variety of policy types as well as support various implementations. There are several mature policy specication languages available including Ponder (Damianou et al., 2001) and Rei (Kagal et al., 2003). Any specication language must have sufcient structure to permit a formal examination of the properties of a given policy and identify adherence to stated requirements. An additional requirement is imposed by a WSN; evaluation of policies specied in the language must express the security policy in a way that is compatible with the limited resources of a WSN node. The WSN Authorization Specication Language (WASL), described below, has its formal basis drawn from ASL (Jajodia et al., 1997). We chose ASL due to its simple yet sufciently expressive language constructs which can support a wide variety of policies. Furthermore, ASL provided an efcient means of composition and placed relatively a modest burden on the gateway node that is assumed to be in the WSN under study. Thus, ASL was deemed especially suitable for this environment. A WASL policy has three kinds of statements: identiers (constant or variable terms), relational statements, and rules. The type-hierarchy of statements is shown in Fig. 1; the indicates an abstract supertypea supertype of which there are no specic instances. The semantics of the term policy is limited to specic authorizations (Auth statements) while the policy environment includes the remaining statement types and rules discussed in detail in Section 3.4. A policy is expressed in WASL as a set of Statements contained within a Block. Alpha-numeric constants and variables identify the systems entities and must be declared as terms of IdDecl; Relations identify relationships among terms and are expressed as rt1 ; . . . ; tn where r is the relation symbol and ti are the constant or variable terms appropriate for r. The primary Relations are the statements Dirin, In, Active, Equals, Leveltype, Inlevel, Levelorder, Levelgeq, and Done. A Rule asserts that when some condition is met, Relational statement in the Rule is true; variable terms are found only in Rules. Error is a special Statement that is a consequence in some Rules or when specication errors are identied; the presence of this statement in the policy indicates a contradiction in the assertions of the policy. Authorizations are expressed through the Relation statements called AuthTypes: Act, Do, Cando, and Auth. Discretionary authorizations (authorizations based on the system administrators determination) are expressed using Act and Cando while Do enumerates mandatory (rule-based) authorizations. Auth is used to express the authorizations for a system. All of the above statement types establish the policy used to determine a systems authorizations; these terms are expressions of the authorizations of each user to the various objects using the Auth statement type. The differences between WASL and ASL (Jajodia et al., 1997) include the following, with some language elements added to focus on security levels and their hierarchy:

Fig. 1. Statements in WASL.

D.W. Marsh et al. / The Journal of Systems and Software 82 (2009) 101111

103

 Relations do and cando represent mandatory and discretionary accesses, respectively (e.g., do(User1, Obj2, Read)).  Relation auth expresses system authorizations (authorization decisions, e.g., auth(User1, Obj2, Write)).  Type level identies the systems security levels (e.g., const level Unclass).  Type leveltype identies the category of security levels as associated with the leveltype relation (e.g., const leveltype BLP; leveltype(Unclass, BLP)).  Relation inlevel(e,l) associates entity e (a user, group, object, or kind) with l (a level).  Relation levelorder(l1,l2) creates one relationship in the security level hierarchy (from l1 to l2) where l1 is higher than l2.  Relation levelgeq(l1,l2) identies level l1 as greater than or equal to level l2. Additionally, whereas ASL expresses facts implicitly within rules, WASL generates an exhaustive, explicit expression of authorizations. This listing requires the assertion of facts via relational statements. Section 3.1 presents the grammar and syntax and is followed by respective descriptions of the semantics of terms, relations, and rules in Sections 3.2, 3.3 and 3.4. Section 3.5 discusses the process of compilation, identifying steps that are slightly modied for composition as presented in Section 3.6. 3.1. Grammar A detailed specication of WASL grammar, with accepted inputs presented in Table 1. This grammar species all the inputs that can be parsed by the WASL compiler. Typewriter text in the table identies terminal symbols while italics identies non-terminals. Alternatives are captured within square brackets with options sep-

arated by the vertical bar. A question mark (?) following the brackets of an alternative identies an optional entry, an asterisk () identies any number of (zero or more) sequential appearances of the alternative, and a plus sign (+) identies there are one or more appearances. The terminal str is specied such that any number of any characters may be used, with the exceptions of newline symbols and the period (). str terminates with a period. Note that a policy expressed in WASL begins with begin and ends with end. Additionally, every statement is terminated with the semicolon (;). Just because a program can be parsed does not guarantee the input is acceptable, but grammatical requirements guarantee a structure that can be analyzed for proper semantics as described in other sections. 3.2. Declarations of terms Every WASL term is of an IdType of role, level, leveltype, subject, group, user, target, object, kind, or action. As the hierarchy shown in Fig. 2 illustrates, the user and group types specialize the subject and, similarly, the kind and object specialize target. System entities include both subjects and targets. The indicates entity terms are supertypes that cannot be instantiated while the identies subject and target terms supertypes that can be instantiated but are restricted to variable terms (e.g., a const target declaration is an error). The special subtype of action (SIGNEDACTION) is not shown in the gure but attaches a unary operator of + or to the action within an AuthType statement to signify the given relationship as a positive (permitted) or negative (disallowed) authorization. The following restrictions provide unambiguous semantics for terms.  Terms may be declared as either constants or variables.  Term labels begin with an alpha character but contain any number of alpha-numeric characters.  No label in a policy may be used more than once.  A subject term is always a variable, appearing only in relation expressions (see Section 3.4). User and group terms are the constants of this type.  A declared role must be a constant.  Variable terms may appear only within rules.

Table 1 WASL grammar Element ? Construction Policy ? begin Stm; end; Stm ! IdDecl j RelStm j ErrorStm j RuleStm IdDecl ? [const j var] [action j group j kind j level j object j role j subject j target j user j leveltype] id ErrorStm ? error(str) RelStm ? [ act (id, id, [+ j -]? id [, id]+) j active (id, id) j auth (id, id, [+j-]? id [, id]*) j cando (id, id, [+j-]? id) j dirin (id, id) j do (id, id, [+j-]? id) j done (id, id, id [, id]*) j equals (id, id) j in (id, id) j inlevel (id, id) j levelgeq (id, id)] j levelorder (id, id) j leveltype (id, id) RuleStm ? Exp => RelStm Exp ? [ true j Exp [& j j] Exp j [-]? (Exp) j [+j-]? RelStm] id ? [a z j A Z][a z j A Z j 0 9]* str ? ($[n n j nr jcdot])* []

3.3. Relations Twelve relations further develop the policy by giving context to the terms and their types. Relations semantics are dened according to the in-order parameter requirements identied in Table 2. In this table the symbol indicates the associated set may be empty while the + identies a necessarily non-empty set. The discussion below uses the following labels as representatives of the given types: subject s, user u, group g, target t, object o, kind k, level l, leveltype lt, action a, and signed action a (representing the expression +a or a). A term that can be a subject or target

Fig. 2. Types of terms (identiers) in WASL.

104 Table 2 WASL Relation Term Requirements Relation act active auth cando dirin do done equals in inlevel levelgeq levelorder leveltype

D.W. Marsh et al. / The Journal of Systems and Software 82 (2009) 101111

(Ordered term types) (subject, target, signedaction, {role}+) (user, role) (subject, target, signedaction, {role}*) (subject, target, signedaction) (entity, group or kind) (subject, target, signedaction) (user, object, action, {role}*) (id, id) (entity, group or kind) (entity, level) (level, level) (level, level) (level, leveltype)

(or any of their subtypes) is identied as e while the terms (id) that can be of any type are x1 and x2.  act(s, t, a, {r}+) species discretionary access controls with the additional requirement that each role in {r} be active.  active(u, r) denes role r as active for u.  auth(s, t, a, {r}*) expresses system-authorized accessthe system authorizations.  cando(s, t, a) is used to express discretionary access controls; s is allowed (forbidden) to perform a on t.  dirin(e, g j k) denes e as an immediate member of g or k.  do(s, t, a) is used to express mandatory access controls; s is permitted to perform a on t based on a set of rules.  done(u, o, a, {r}) denes an access that has occurred; has performed a on o with role(s) {r} for u active.  equals(x1, x2) appears only in the conditional expression of rules and identies that x1 is the same term as x2.  in(e, g j k) denes e as a member of g or k, although not necessarily an immediate member.  inlevel(e, l) denes e as being in security level l.  levelgeq(l1, l2) appears only in the conditional expression of rules and identies that l1 is at the same or a higher security level than l2.  levelorder(l1, l2) denes l2 as the next lower security level than l1.  leveltype(l1, lt) denes l2 as the lt type of security level. Level ordering is different than entity grouping in that security levels have a strictly controlled hierarchy. A subject or target may be identied as indirectly belonging to a group or kind (using in) while applying the levelorder statement indicates the hierarchy of levels. This, along with a check for loops in the level ordering during compilation, ensures a partial ordering of the security levels. Evaluation of the relation levelgeq, a relation that appears only in expressions (see Section 3.4), checks levelorder entries to determine whether they are true or false. The error statement is similar to a relation statement, but is unique because it relates no terms. It does, however, have a text eld that provides feedback regarding a problem in the policy (e.g., error(DoStm conflict for do(User3, Obj2, -Write)).). 3.4. Rules The rule construct was initially intended to capture a policys mandatory authorizations. For example, it is used to easily express the relationships between subjects, objects, levels, and actions necessary to sustain the prescribed denition of security. Rules may also be used by the system administrator, however, to quickly dene relationships that authorize or prohibit certain actions.

Rules consist of a relation expression re (the condition) and a relation statement rs (the consequent). Any re is a Boolean expression of zero or more relations linked together and operated upon by logical operators; unary operators are + (PLUS) and (MINUS) while binary operators are & (AND) and j (OR). An empty re implies true. Relations r that appear in re may have variables and constants as terms or both. A relation expression +r, where r is a constant-only relation in re, evaluates to true if and only if it appears in the policy; it evaluates to false otherwise. r yields the opposite result. Any r in re with variable terms cannot be evaluated true due to the variables, but it can be evaluated false if the existing constants do not match the patterns present in the statements of the policy. This handling of relations is the basis for evaluating binary expressions, with & and j providing the logical conjunction and disjunction, respectively. Resolving rules is accomplished by substituting constant terms from the policy for the rules variables, ensuring the typing of terms is maintained. The variable-free statement rs of a rule is added to the policy when re of the same rule evaluates to true. Several requirements are associated with rules:  A rule with an auth statement in the condition must have an auth statement as the consequent. A rule structured this way is used only during composition. This is due to the semantics of the various relation statements.  The consequent of a rule must be either an authorization type (do, cando, act, or auth) or an error. All other relations are explicitly specied or inferred during compilation.

3.5. Compilation The WASL compiler performs two functions: compilation of the expression of the policy in WASL (a policy program) and policy composition. Compilation leads to the complete delineation of system authorizations with constant-only terms. Composition is addressed in Section 3.6. Compilation of a WASL program generates a set of ground authorizations or auth statements. Compilation includes lexical analysis, parsing, semantic analysis, and code generation. The textual input is conned to the grammar specied in Table 1 and the output, consistent with the same grammar, includes the original input, statements deduced from the input, and the generated set of ground authorizations. The sequential steps of compilation follow. (1) Analyze the input for proper grammatical structure and store it in an intermediate representation useful for program analysis (lexical analysis and parsing). (2) Bind each term to its declaration to ensure, for example, Mote32 always refers to const user Mote32 (semantic analysis, part 1). (3) Resolve types; for example, parsing identies the subject in a do statement as a subject where it may actually be a user or group according to its binding. (semantic analysis, part 2). (4) Check structural requirements; for example, a rule must have as its consequent either an error or an authtype statement, security levels must be arranged in a partial order, and entities must not be in multiple security levels within a given partial order (semantic analysis, part 3). (5) Analyze relations to determine any possible derived in, inlevel, and kindof relations (semantic analysis, part 4).

D.W. Marsh et al. / The Journal of Systems and Software 82 (2009) 101111

105

(6) Identify rules that do not generate system authorizations and iterate through the set of variables they contain. (a) Identify and iterate through constants matching the variables type. (i) Iterate through rules requiring a substitution, replace the variable with the constant to create a new rule. (ii) Simplify and evaluate the condition of the created rules. (iii) Add to the program consequents corresponding to conditions that are true. (iv) Store the rules to replace the next variable if further constant-for-variable substitutions are required. (b) Repeat with the next variable in Step 6 using the stored rules from Step 6a.iv. (7) If any relations have been added to the program, repeat from Step 6. (8) Perform the iterations of Step 6 using the rules that generate system authorizations and the set of variables they contain. Policies may express different types of authorizations using a variety of terms: mandatory accesses, discretionary accesses, access control lists, and rule-based accesses are just a few. WASL relations model these using act, do, and cando relations. The generation of system authorizations relies on the proper expression of security rules to specify how the interaction of these constructs results in system authorizations. Compilation thus results in the desired set of system authorizations identifying the authorizations of the system. This complete expression of system authorizations is sufcient for a system operating independently of all other systems. However, as soon as interactions with external networks is necessary, policy composition is required. 3.6. Composition Composition in WASL uses the above compilation procedures to merge multiple policies by adding rules that provide cross-policy interactions. Suppose there are independent systems A and B, in which subjects from one need to interact with objects from the other; policy composition ensures the security policies dened individually within A and B is maintained while permitting additional authorizations so subjects in A access objects in B and/or vice-versa. In such a system both the authorizations and prohibitions in effect under isolated systems A and B must be preserved. We refer to a system that meets these initial requirements as being compatible with the original. Additionally, the interaction of A with B should be consistent, not leading to direct or indirect violations of either of the policies. The compatibility requirement is partially met by a composition when all authorizations in a policy are also in the compositions resultant ground terms. When a composition meets this condition and, additionally, when every action that is disallowed by a policy is also disallowed in the composition, compatibility is fully satised. Both of these conditions are met by requiring any additions to system authorizations to have subjects and targets from separate systems. Thus, changes to a given systems policy cannot be accomplished via composition; a change to a policy representation requires recompilation. Consistency is achieved when data ows prohibited in the individual policies are also prohibited in the composition. Direct violations are addressed by the correctness description above. Indirect violations are prohibited by ensuring a partial order of security levels between systems is established and maintained.

Consider the following example of an indirect violation. Suppose a user u under policy A is not permitted read access to object o (i.e., either the expression -auth(u, o, read) or auth(u, o, -read) is true). After composition with policy B, u1 (under policy B) is authorized to read o authu1 ; o; read and write o1 authu1 ; o1 ; write. If u is authorized to read o1 authu; o1 ; read, this indirectly violates the policy for system A since u could read o data written to o1 by u1 . This situation cannot occur when security levels are properly ordered during composition. WASL policy composition applies elements of an algebraic framework used for composing access control policies similar to those in (Bonatti et al., 2002). The method permits independent policies to maintain access restrictions for systems within an environment of heterogeneous policies while adding a combined, interpolicy access specication. In this framework policy identiers P x are distinguished by their subscript x and are associated with sets of relations including ground authorizations through the partial mapping established by the environment e. The mapping of system authorizations and other non-authorization relations associated with Px are identied by the annotation Px e . The algebraic operators used here include addition (+), conjunction (&), and closure () using a set of rules and other statements R, each summarized in Table 3. The closure function generates all permitted authorization terms by applying a set of inference rules R to a policy. Applying this composition framework to a WASL-specied system leads to the representation of compositions using the form closureR; P 1 e [ P2 e . An immediate requirement following from the addition of policies is that terms be unambiguous; identiers used for users, objects, or other elements under policy P 1 must not be confused with elements under policy P2 . As mentioned before, compatibility requires that any new authorizations generated by rules and other relations identied in R must include subjects and targets from different systems (i.e., if the subject is under P 1 the target must be under P2 and vice-versa). The addition of relations specifying an acceptable (partially ordered) security level hierarchy along with rules that enforce the appropriate policy ensures consistency. For an effective implementation in WASL, policies to be merged must include the ground authorizations, the other nonauthorization relations, and the declarations of any terms included in these authorizations. Authorization relations used to generate the ground authorizations during compilation (i.e., authorizations other than ground authorizations) are not required for composition as they are useful only during compilation. Additionally, non-ground term authorizations associated with either of the policies being composed are removed prior to composition because they could result in inappropriate ground terms under composition. Thus, the annotation Px e of a policy that is to be compiled represents a slightly smaller set of statements than the entire representation of policy P x . Rules generating system authorizations during compilation are applied again during composition to ensure consistency of the resulting policy.

Table 3 Composition operators, symbols, and semantics Name Addition Conjunction Closure Smb + & * Denition P 1 P 2 e P 1 e [ P 2 e P 1 & P 2 e P 1 e \ P 2 e P Re closureR; Pe )
def def def

106

D.W. Marsh et al. / The Journal of Systems and Software 82 (2009) 101111

Thus, under composition: (1) Subjects and targets in system authorizations generated by composition rules must come from different systems. (2) Terms between policies must be unambiguous (i.e., a given term identier must represent exactly one term). (3) Excepting system authorizations, authorization statements associated with one or the other of the policies to be composed must not play a role in composition. (4) Composition rules generating system authorizations must be the same as those used for the composition of the individual policies. The sections above provide a comprehensive presentation of WASL, its compilation, and WASL-encoded policy composition. We now turn our discussion to the systems in which policies are enforced. 4. Network under study This section examines the limitations of WSNs that led to certain design decisions. For example, due to bandwidth, memory, and processing power limitations nodes do not perform compilation or composition; these functions are performed at the gateway. WSN characteristics are presented in Section 4.1 while policy-related responsibilities are discussed in Section 4.2. 4.1. System characteristics The WSN under consideration is a query-based system with dozens to thousands of resource-constrained nodes and a more powerful gateway computer. Each of these characteristics impacts implementation decisions discussed in Section 4.2 and the interpretation of results in Section 5. In a query-based system information is transferred primarily as a result of requests for data. This can also be thought of as a pulloriented rather than push-oriented system; the node does not automatically send its data to nearby nodes but instead responds to queries for data. Queries may be received by one or more network nodes and, if the query arrives at a node other than the intended destination, it is routed appropriately. Queries may originate at nodes external to the WSN. No assumptions are made about these nodes other than that they are capable of communicating with the nodes in the WSN, including authentication with a verication of security properties. The external nodes may be participating in a network that functions under a security policy distinct from that of the WSN. The provision for handling queries when the querying subject is external to the WSN is addressed by composition, presented in Section 3.6. Each node in the WSN may respond to a query and participate in any query-response exchange as a message router in the network. Given that messages may be classied or protected at different security levels, it is assumed that each node has a trusted kernel, secure to the highest level of security in the WSN. Thus, regardless of the security level at which a node functions, the trusted kernel can process messages at higher security levels. The gateway is a laptop-class node that functions as the administrative hub of the WSN. Policy or other software updates are distributed from this node and it generally functions as the interface between the WSN and external networked devices. Because the WSN may be highly distributed, it is not assumed that it can communicate directly with each of the nodes in the network. Nor is it assumed that a response from a node must pass through the gateway before being received by an external node.

Data communicated to, from, or within the network is encrypted at an appropriate level and all users adhere to an authentication scheme. Each query is thus secure with respect to condentiality and integrity while in transit. Additionally, because the querying user is properly identied, policy information can be effectively used to determine appropriate responses. The policy itself is expected to change over time with users or groups being added or their authorizations modied. But these changes are assumed to occur infrequently. 4.2. Distribution of responsibilities The primary policy-related tasks include the following: (1) Control of the administrators WSN security policy specication. (2) Compilation of the WSNs policy. (3) Collecting external networks possibly partial policy specications. (4) Composing the WSNs policy with other policies. (5) Compressing the resulting system authorizations for distribution and storage. (6) Distribution of system authorizations. (7) Storage of system authorizations. (8) Choosing the proper response when queried. The minimal capabilities of nodes necessarily require that many of these tasks be performed at the gateway. Additionally, while the system administrator has access to the gateway, system authorizations are distributed to the nodes via wireless communications. The gateway, therefore, is the sole node in the system that performs tasks 1 through 5. These tasks include the original WASL expression of the policy, the compilation of the policy, and the management of the tasks related to establishing a secure basis for interactions with external networks nodes. Task 6 begins at the gateway, but is also shared by every node in the WSN. It is expected that many nodes will receive data and system authorizations to be retransmitted to other nearby nodes. Each node must store at least those system authorizations that are pertinent to its own operations or data accesses; this is expressed in task 7. Tasks 7 and 8 could be implemented in two ways. One way is to have a node store every system authorization; the other is to store only those system authorizations related to objects maintained at the node. The following discussion addresses the options. In either case, all the system authorizations must be distributed throughout the WSN so the nodes have all the system authorizations they need. For the rst alternative an obvious impact is the use of a nodes memory. Storing all authorizations requires signicantly more memory but has the benet of mitigating a class of denial of service attacks; when a node has access to every system authorization it determines whether to respond to or forward a query. We assume nodes ignore queries by entities not specically authorized by the security policy, thus reducing the number of query transmissions within the WSN at the cost of increased memory usage and slightly more computation by a node. The second alternative reduces the memory required at each node, potentially signicantly, depending on the number of authorizations and the scheme used for system authorization representation. This decision, however, means each node will forward any queries intended for another node which may result in a much larger energy expenditure due to the forwarding of unauthorized queries. Every node performs task 8every query is evaluated with respect to the system authorizations prior to the generation of a

D.W. Marsh et al. / The Journal of Systems and Software 82 (2009) 101111

107

system response. For authorized queries the queried node performs the computations and/or transmissions in response to the query as appropriate. Generally it is expected that answers to queries are routed to the gateway for transmission to inter-network nodes as appropriate because nodes have a very limited effective transmission range. It is possible, however for an inter-network node to receive the answer directly from a node. We assume queries are routed to their intended destination, where they are compared to system authorizations. 5. Results A straightforward implementation of a WASL system has been created to read, compile, and compose security policies. The system is nave in that it implements the algorithms described above with few optimizations. Policies for the networks described above are specied in WASL and compiled. The resulting system authorizations are combined using composition rules to yield new sets of system authorizations that are compatible and consistent with the original security policies. System authorizations are compressed to a reasonable size for transmission throughout a WSN and for storage on a node. A simple policy and its compilation in WASL is presented in Section 5.1, an example of policy composition follows in Section 5.2, and observations regarding the size of the policy as relates to the feasibility of implementation in a WSN are provided in Section 5.3. 5.1. WASL-instantiated policies A policy implementing the BellLaPadula (BLP) notion of condentiality provides a useful introduction of WASL representations. Designed to mimic the military classication system, the BLP model prevents information at a given classication level from being leaked to a lower classication level. The presentation here describes a simple system with two users, groups, objects, kinds, and actions. Key to BLP representations is the domination relationship for each pairing of security levels. Given two security levels S and U, where S is the higher classication level, S dom U; S dom S, and U domU hold, U dom S does not. No reads up and no writes down sum up the prohibited actions in BLP. That is, no information classied at a higher-level may be written to a lower-level object and no user at a lower classication level may read higher-level data. These rules are mandatory for a system implementing the BLP model. Discretionary access controls must be dened as well and can enforce such concepts as a need to know, but the discretionary controls may not permit accesses that are denied by mandatory access rules. The WASL specication code that follows denes policy J for a WSN with two users belonging to different groups, two objects of different kinds, and the security levels of the groups and kinds. The levelorder relation identies level JS is a higher classication level than level JU. Similarly, levelgeq species the dom relationship between level variables and is critical to the enforcement of the no reads up and no writes down requirement. For its discretionary access controls the system allows all possible rights for subjects and targets given the actions Read and Write, but system authorizations are limited to those complying with BLP Model requirements. begin declare users, groups, objects, kinds, and actions const user JU1; const user JU2; const group JGS; const group JGU; const object JO1; const object JO2; const kind JKS; const kind JKU;

const action Read; const action Write; declare security levels and establish hierarchy const level JS; const level JU; levelorder(JS, JU); relate users to groups and groups to levels dirin(JU1, JGS); dirin(JU2, JGU); inlevel(JGS, JS); inlevel(JGU, JU); relate objects to kinds and kinds to levels kindof(JO1, JKS); kindof(JO2, JKU); inlevel(JKS, JS); inlevel(JKU, JU); declare user, object, action and level variables var user u; var object o; var action a; var level level1; var level level2; specify maximal discretionary rights true ) cando(u, o, a); incorporate the two BLP rules cando(u, o, Write) & inlevel(u, level1) & inlevel(o, level2) & levelgeq(level2, level1) ) auth(u, o, Write); cando(u, o, Read) & inlevel(u, level1) & inlevel(o, level2) & levelgeq(level1, level2) ) auth(u, o, Read); end; Policy J identies discretionary rights by group and kind with user and object interactions deduced during compilation. Compilation produces additional relations, inlevel and cando statements in this case, shown below (comments added): user-level and object-level relationships inlevel(JU1, JS); inlevel(JU2, JU); inlevel(JO1, JS); inlevel(JO2, JU); discretionary rights cando(JU1, JO1, Write); cando(JU1, JO1, Read); cando(JU1, JO2, Write); cando(JU1, JO2, Read); cando(JU2, JO2, Write); cando(JU2, JO2, Read); cando(JU2, JO1, Write); cando(JU2, JO1, Read); Discretionary authorizations are examined in light of mandatory authorization rules to ensure the system authorizations consistent with a secure system dened by the BLP Model. system authorizations for JU1 auth(JU1, JO1, Write); auth(JU1, JO1, Read); auth(JU1, JO2, Read); system authorizations for JU2 auth(JU2, JO2, Write); auth(JU2, JO2, Read); auth(JU2, JO1, Write); The above example demonstrates the functionality of the language and policy representations. Rigorous analysis shows that BLP and other security models are properly implemented has been completed but is beyond the scope of this paper. We advocate the distribution of system authorizations, and only system authorizations, throughout the WSN due to network and node resource constraints. The response of a node to a query is to simply determine if an authorization is present. If not the query is not answered. Composition increases the utility of this lightweight approach. 5.2. Policy composition We expect greater degrees of WSN inter-networking in the future to require a policy management system that includes users from external networks that are operating under distinct security policies. Thus, policy composition is used to identify permitted

108

D.W. Marsh et al. / The Journal of Systems and Software 82 (2009) 101111

cross-policy interactions while maintaining the distinct policies of each network. A formal composition framework in (Bonatti et al., 2002) was designed for this purpose and is adapted to WASL constructs. An example of composition follows, using policy J above and the newly introduced K. Composition uses only system authorizations (auth statements) and composition rules. The same actions, Read and Write, are used in both systems. Policy K is like policy J with two each of users, groups, objects, kinds, and security levels. The actions and rules are also the same, consistent with the BLP Model. The structural difference is in the discretionary accesses beginning at line 19. 1. begin 2. declare users, groups, objects, kinds, and actions 3. const user KU1; const user KU2; const group KGS; 4. const group KGU; const object KO1; const object KO2; 5. const kind KKS; const kind KKU; 6. const action Write; const action Read; 7. declare security levels and establish hierarchy 8. const level KS; const level KU; 9. levelorder(KS, KU); 10. relate users to groups and groups to levels 11. dirin(KU1, KGS); dirin(KU2, KGU); 12. inlevel(KGS, KS); inlevel(KGU, KU); 13. relate objects to kinds and kinds to levels 14. kindof(KO1, KKS); kindof(KO2, KKU); 15. inlevel(KKS, KS); inlevel(KKU, KU); 16. declare user, object, action, and level variables 17. var user u; var object o; var action a; 18. var level level1; var level level2; 19. specify discretionary accesses 20. cando(KU1, KO2, Write); 21. true ) cando(u, KO1, Read); 22. true ) cando(KU2, KO2, a); 23. incorporate the two mandatory access rules for BLP 24. cando(u, o, Read) & inlevel(u, level1) 25. & inlevel(o, level2) & levelgeq(level1, level2) 26. ) auth(u, o, Read); 27. cando(u, o, Write) & inlevel(u, level1) 28. & inlevel(o, level2) & levelgeq(level2, level1) 29. ) auth(u, o, Write); 30. end;

The union of specications for J and K with appropriate rules provides cross-system accesses. Suppose the administrator of J allows Read access of objects in level JU to all the users in K. The administrator assigns level JU to group KGU, establishes the desired discretionary rights, and performs composition with the BLP rules. The following code, along with the same BLP rules used in the individual policies, is sufcient to perform the desired composition as is demonstrated below. The composition statements (represented by R in Section 3.6) include associate Ks groups with level JU inlevel(KGU, JU); inlevel(KGS, JU); rule to generate K to J low-level read access (in(u, KGU) j in(u, KGS)) & kindof(o, JKU) ) cando(u, o, Read); Performing the composition J K&Re rst generates the new relations K users associated with level JU inlevel(KU2, JU); inlevel(KU1, JU); discretionary authorizations for composition cando(KU1, JO2, Read); cando(KU2, JO2, Read); and leads to the generation of the desired system authorizations, consistent with the mandatory rules of the BLP model: composition-generated system authorizations auth(KU1, JO2, Read); auth(KU2, JO2, Read); The composition permits all the accesses originally provided by J and K in their respective networks and does not add accesses that are disallowed in the separate systems, thus preserving security within the individual networks. The added authorizations also sustain security for the composed system JK by permitting only Read access to objects at the low security level in J by users in K, authorizations consistent with the BLP model of security that is implemented. Permitting data to ow in only one direction prevents indirect data ows that could violate security. Formalizations including proofs of security in BLP systems and of other formally-modeled security systems can show whether a resultant system remains secure with respect to dened security requirements but are beyond the scope of this paper. Security depends on the composition rules and their interaction with the external system. Security for each of J and K can be proven before and after composition. In the same way, security for the composed system can be proven and, thus, the entire system is provably secure according to the axiomatic system (e.g., the BLP Model) dening security. For this example, the Read authorizations are for the userobject pairings JU1JO1, JU1JO2, JU2JO2, KU1KO1, KU2KO2, KU1JO2, and KU2JO2. In every case the security level of the user dominates the security level of the object. Write authorizations are for userobject pairings JU1JO1, JU2JO2, JU2JO1, and KU2KO2. For these cases the security level of the object dominates the security level of the user. Thus, the composed system is secure because these relationships are consistent with the BLP denitions described above as no reads up and no writes down. Like initial policy compilation, composition must be completed on a node more powerful than a node. When a new system must interact with the WSN, the possibility of the transmission and storage of the policies of external networks quickly becomes untenable. But it is also undesirable to store an abundance of authorizations at each node.

The discretionary accesses for K are: discretionary rights cando(KU1, KO1, Read); cando(KU1, KO2, Write); cando(KU2, KO2, Read); cando(KU2, KO2, Write); cando(KU2, KO1, Read); These discretionary controls are more tightly dened than those of policy J. None of the users are authorized to Write to KU1 and KU2 is permitted to Write KO1. The discretionary accesses are compared with the mandatory access rules to generate the following system authorizations: system authorizations auth(KU1, KO1, Read); auth(KU2, KO2, Write); auth(KU2, KO2, Read);

D.W. Marsh et al. / The Journal of Systems and Software 82 (2009) 101111

109

5.3. Suitability of WASL for a WSN This section examines implementation issues and shows it is reasonable to transmit and employ the system authorizations of composed policies at WSN nodes. The data in this section was generated using a Java Compiler Compiler (JavaCCTM) for WASL grammar checking and an abstract syntax tree for semantic checking and further manipulations. (Information regarding the syntax tree methodology used can be found in (Appel, 1998)). A WSN may be composed of hundreds, if not thousands of nodes. The number of objects in the system could be equally large, with some data available on a by-node basis. The possible actions that must be controlled by a policy are expected to be small, but a policy for 1000 nodes and 1000 objects with six actions has 6,000,000 potential authorizations. If a unique binary number identies each authorization, the representation requires nearly 3 bytes to express (222 < 6; 000; 000 < 223 , so 23 bits per authorization are required). Additionally, a policy of this size would be prohibitively large to compile. Nodes are likely in one or more groups, so there would be 1000 or more statements capturing these relationships. Similarly, the 1000 objects would be of one or more kinds, leading to at least 1000 more statements. A simple rule might contain two variables, one of type object and one of type subject, and two relation expressions; compilation will require up to 1000 1000 term substitutions and the evaluation of the same number of expressions. As the size of the policy increases, the worst case scenario is a factorial expansion of the required compilation time. Memory required to store this information grows at a similar rate. Representing the policy via rules at each node is an equally unappealing option, given the characteristics just described. Either the nodes would be required to store membership and other information about entity relationships or much of this information would be required in each query. The cost in memory, computational requirements, or transmission bandwidth for this is prohibitive. Separate node identiers, however, are unlikely. More probable is a limited number of node groups and the kinds of data manipulated. Using WASL to specify system authorizations by group and/or kind signicantly decreases the volume of information required to determine whether or not a request is authorized. Improvements on the proposed process of policy system authorization distribution, however, can also be made. Data compression methods, for example, decrease the bandwidth required for policy transmission even further as it reduces memory consumption at the nodes. This being so, the following alternative approach takes advantage of WSN characteristics. Consider a network with thousands of nodes but only three user groups, ve-object kinds, and four possible actions. Thus there are only 60 possible authorizationsa policy size that, using the simplistic binary encoding described above (one byte per authorization with 60 bytes maximum), is a reasonable size to transmit and store at a node. The processing needed to determine whether a request is authorized is equally modest. Authorizations stored in a table indexed by a concatenation of user group and object kind can be retrieved via table look-up which returns the allowed actions for that group/kind pair. These allowed actions are compared to the requested action. Using the above encoding scheme, this can be done in three instructions: (1) read memory, (2) perform a logical AND of authorized actions with requested action, (3) branch to an appropriate location based on the result. Policy compilation speed trials have been performed on a notebook computer with 1300 MB of memory and an AMD Athlon 3400 processor running at 2.2 GHz. Each network had two groups, two kinds, two levels, and two actions with a varying number kUk of users (where kUk is the size of set U) and kOk of objects uniformly distributed across groups and kinds as appropriate, with

the latter two also uniformly distributed across levels. The twoactions are read and write while the groups (user types) and kinds (object types) correspond to secure and unsecure condentiality levels. A dirin statement associates each element of U with exactly one group while a kindof statement identies objects in O as exactly one kind. The two rules identied in the examples above cando(u, o, Read) & inlevel(u, l1) & inlevel(o, l2) & levelgeq(l1, l2) ) auth(u, o,Read); cando(u, o, Write) & inlevel(u, l1) & inlevel(o, l2) & levelgeq(l2, l1) ) auth(u, o, Write); specify the condentiality requirements of the BLP model (Bell and LaPadula, 1975). When using true ) cando(u,o,a) to generate discretionary control accesses for the two-action system, 2 kUk kOk term substitutions replace the action, users, and object variables to generate 2 kUk kOk discretionary authorizations. Next, on the order of kUk kOk 2 2 term substitutions replace the variables u, o, l1, and l2 with the users, objects, and security levels in the system. Execution times, however, grow at a rate much greater than kUk kOk. Table 4 contains the compilation times with the 95% condence interval for a two-level BLP security system with twoactions, ve-objects, and a number of users ranging from 10 to 1000. System authorizations are based on discretionary authorizations that provide all possible authorizations for every userobject pairing using the rule true ) cando(u,o,a) and the two BLP mandatory access control rules. Each compilation was run 10 times with interfering processes on the laptop kept to a minimum. Runs have also been completed for a variety of other combinations of users and objects including a run with 60 objects and 60 users requiring 214.282 s and another with 50 objects and 100 users requiring 449.4 s. Nodes in a WSN are unlikely to be managed individually, that is, with distinct authorizations per node. We expect to nd groups of nodes performing similar functions throughout the WSN and authenticating by type rather than as an individual node. Not only is this more efcient from a policy distribution perspective, it makes the network more resilient to changes in topology that occurs due to depleted batteries, node malfunction, or the introduction of new nodes. To match this expectation test runs have been made using rules focused on groups rather than individual users. Compiling the policy for a WSN with 100,000 nodes associated with ve groups, with the same number of other parameters described for Table 4, and focusing the rules on granting authorizations by group association, the compilation time is 0.05 s as shown in the table. Because the particular users are not a factor,

Table 4 Five-object BLP policy compilation times # Users 10 20 30 50 70 100 200 300 500 700 1000 N/Aa Compilation time (s) 0.15 0.01 0.15 0.01 0.22 0.01 0.49 0.01 0.92 0.11 1.61 0.06 5.75 0.27 12.67 0.57 37.31 1.11 71.62 1.14 138.47 2.71 0.05 0.005

a Authorizations are identied by group with a ve groups. The number of users can grow without impact to the compilation time.

110

D.W. Marsh et al. / The Journal of Systems and Software 82 (2009) 101111

Table 5 Times for composition of a ve-object, 10-user system with a ve-object, X-user system # Users 10 20 30 50 70 100 200 300 500 700 1000 Composition time (s) 0.16 <0.01 0.25 0.04 0.31 0.04 0.48 <0.01 0.57 0.01 0.81 0.01 1.89 0.05 3.25 0.04 6.57 0.06 10.24 0.04 16.84 0.06

Table 6 Times for composition of a ve-object, X-user system with a ve-object, 10-user system # Users 10 20 30 50 70 100 200 300 500 700 1000 Composition time (s) 0.14 <0.01 0.24 <0.01 0.42 0.06 0.71 0.11 1.09 0.06 1.87 0.04 8.29 0.21 19.09 0.40 57.36 0.55 122.64 0.53 255.09 0.62

WSN is isolated from outside users. While a continually changing security policy is untenable with respect to the resources in a WSN, sensor networks of the future will likely require increasing interactions with external nodes. WASL is a policy language capable of representing arbitrary policies such as BellLaPadula, Biba, or the Chinese Wall. WASL supports policy composition and preserves security in the individual systems while enabling cross-network communications. WASL and its associated compiler/composer provides the foundation for a policy-enforcement system in which the policy may be changed without modication of the enforcement mechanisms. This is a new capability for query-based WSNs that adds to their exibility and security. Tests indicate that reasonably-sized policies with several objects and up to 1000 users/groups can be compiled and composed with other policies on a notebook-class computer. As long as the number of entities represented in the system is not too great, the resulting policy can be represented in a way that is reasonable to transmit to and process at a typical WSN node. The number of entities is a crucial measure because as they increase, the time required for compilation increases factorially in the worst case while the space required for policy storage increases linearly. Given a reasonable grouping of users, however, policies for WSNs with hundreds of thousands or millions of nodes can be compiled and effectively implemented. References
Appel, A.W., 1998. Modern Compiler Implementation in Java. Cambridge University Press, New York, NY. Bell, D.E., LaPadula, L.J., 1975. Secure computer systems: unied exposition and multics interpretation. Tech. Rep. MTR-2997, MITRE Corp., Bedford, MA. Benenson, Z., Gedicke, N., Raivio, O., 2005. Realizing robust user. Biba, K.J., 1977. Integrity considerations for secure computer systems. Tech. Rep. MTR-3153, MITRE Corp., Bedford, MA. Bonatti, P., di Vimercati, S.D.C., Samarati, P., 2002. An algebra for composing access control policies. ACM Transactions on Information System Security 5 (1), 135. Crossbow, 2007. MICA2 Datasheet. Crossbow Technology Incorporated, 4145 N. First Street, San Jose, CA 95134. <http://www.xbow.com>. Damianou, N., Dulay, N., Lupu, E., Sloman, M., 2001. The ponder policy specication language. In: Workshop on Policies for Distributed Systems and Networks. LNCS 1995. Springer-Verlag, Bristol, UK, pp. 1839. Di Pietro, R., Mancini, L.V., Mei, A., 2003. Random key-assignment for secure wireless sensor networks. In: SASN03: Proceedings of the 1st ACM Workshop on Security of Ad hoc and Sensor Networks. ACM Press, New York NY, USA, pp. 6271. Donggang, Liu, 2007. Efcient and distributed access control for sensor networks. In: Proceedings of the IEEE International Conference on Distributed Computing in Sensor Systems (DCOSS), Santa Fe, NM. pp. 2135. Gaubatz, G., Kaps, J.-P., ztrk, E., Sunar, B., 2005. State of the art in ultra-low power public key cryptography for wireless sensor networks. In: PERCOMW05: Proceedings of the Third IEEE International Conference on Pervasive Computing and Communications Workshops. IEEE Computer Society, Washington, DC, USA, pp. 146150. Jajodia, S., Samarati, P., Subrahmanian, V., 1997. A logical language for expressing authorizations. In: Proceedings of the 1997 IEEE Symposium on Security and Privacy. IEEE, INSPEC Accession Number: 5602909. pp. 3142. Kagal, L., Finin, T., Anupam, Joshi, 2003. A policy language for a pervasive computing environment. In: Proceedings of the IEEE 4th International Workshop on Policies for Distributed Systems and Networks. IEEE, pp. 6374. Karlof, C., Sastry, N., Wagner, D., 2004. TinySec: User Manual. University of California, Berkeley. Oliveira, L.B., Aranha, D., Morais, E., Daguano, F., Lpez, J., Dahab, R., 2007. Tinytate: Identity-based encryption for sensor networks. Cryptology ePrint Archive, Report 2007/020. Perrig, A., Canetti, R., Song, D., Tygar, J.D., 2001. Efcient and secure source authentication for multicast. In: Proceedings of the Internet Society Network and Distributed System Security Symposium, NDSS01. pp. 3546. Wang, H., Li, Q., 2006. Distributed user access control in sensor networks. In: Proceedings of the IEEE International Conference on Distributed Computing in Sensor Systems (DCOSS), San Francisco, CA. pp. 305320. Zhao, F., Guibas, L.J., 2004. Wireless Sensor Networks: An Information Processing Approach. Morgan Kaufmann Publishers, San Francisco CA. Zhou, Y., Zhang, Y., Fang, Y., 2007. Access control in wireless sensor networks. Ad Hoc Networks 5 (1), 313.

with a constant number of groups the number of nodes can be increased or decreased with no affect on the compilation time or memory required for storage of the policy. Policy composition is an extension of policy compilation that is performed on the combination of two previously-compiled policies. The non-system authorizations of each is removed and composition statements are added in preparation for processing. The time required for composition may be signicantly less than that for compilation, depending primarily on the number of constants corresponding to the variables of the composition rules but also on the number of relations interacting with the given rules. Table 5 shows the time requirements for extending low-level read access from a ve-object, 10-user system (as described in Section 5.2) to similar ve-object systems with the listed numbers of users. The time requirements for extending low-level read access from a ve-object system (with varied numbers of users as listed) to a ve-object, 10-user system is shown in Table 6. Plain text representations of a ve-object 1000-user policy (including all relation statements) as described above requires 578 kB of memory when stored as plain text, but simplifying the representation and representing the authorizations by group rather than by user quickly reduces the size to 458 bytes for the entire set of system authorizations. Assuming a given node interacts with only three of the ve-objects, the storage of system authorizations at a node requires only 210 bytes of memory. While these are more reasonably-sized for transmission to and storage on a node, a representation using a binary code rather than text could compress the code much further. 6. Conclusion Security issues for wireless sensor networks continues to be a challenge. Encryption, authentication, and other existing methods are effective for enforcing certain policies, particularly when the

D.W. Marsh et al. / The Journal of Systems and Software 82 (2009) 101111 David W. Marsh received a B.S. in Electrical Engineering from Seattle Pacic University in 1992, his M.S. in Computer Engineering from the Air Force Institute of Technology in 2000 and his Ph.D. in Computer Science in 2008. He has served 15 years in the United States Air Force and is a member of Eta Kappa Nu, Tau Beta Pi, and IEEE. His research interests include computer security, software analysis, software engineering, and computer communication networks.

111

for seven of those years. He is a registered Professional Engineer in Colorado and a member of Eta Kappa Nu, Tau Beta Pi, IEEE (senior member), and ASEE. He has received the U.S. Air Force Academys Outstanding Academy Educator award as well as the Brig. Gen. R. E. Thomas award for outstanding contribution to cadet education twice. His research interests include cyber operations, computer communication networks, embedded (sensor) and wireless networking, and recongurable computing systems.

Rusty O. Baldwin is an Associate Professor of Computer Engineering in the Department of Electrical and Computer Engineering, Air Force Institute of Technology, Wright-Patterson AFB OH. He received a B.S. in Electrical Engineering (cum laude) from New Mexico State University in 1987, an M.S. in Computer Engineering from the Air Force Institute of Technology in 1992, and a Ph.D. in Electrical Engineering from Virginia Polytechnic Institute and State University in 1999. He served 23 years in the United States Air Force. He is a registered Professional Engineer in Ohio, a member of Eta Kappa Nu, and a Senior Member of IEEE. His research interests include computer communication networks, embedded and wireless networking, computer security, cyber operations, and recongurable computing systems.

Robert F. Mills is an Assistant Professor of Electrical Engineering in the Department of Electrical and Computer Engineering, Air Force Institute of Technology, WrightPatterson AFB OH. He received a B.S.E.E from the Montana State University in 1983, an M.S. in Electrical Engineering from the Air Force Institute of Technology in 1987, and a Ph.D. in Electrical Engineering from the University of Kansas in 1994. His research interests include cyber operations, computer communication networks, cognitive radio, and cognitive radio systems.

Barry E. Mullins is an Assistant Professor of Computer Engineering in the Department of Electrical and Computer Engineering, Air Force Institute of Technology, Wright-Patterson AFB OH. He received a B.S. in Computer Engineering (cum laude) from the University of Evansville in 1983, an M.S. in Computer Engineering from the Air Force Institute of Technology in 1987, and a Ph.D. in Electrical Engineering from Virginia Polytechnic Institute and State University in 1997. He served 21 years in the Air Force teaching at the U.S. Air Force Academy

Michael R. Grimaila (BS, Electrical Engineering; MS, Electrical Engineering; and PhD, Computer Engineering, all from Texas A&M University) is an associate professor and a member of the Center for Cyberspace Research at the Air Force Institute of Technology (AFIT), Wright-Patterson AFB, Ohio. He is a Certied Information Security Manager (CISM), Certied Information System Security Professional (CISSP), and holds NSA IAM/IEM certications. He teaches and conducts research in the areas of information assurance, information warfare, and information operations. He serves as an Editorial Board member of the Information System Security Association (ISSA) Journal and on the DoD/NII IA Best Practices and Metrics Working Group. He is also a member of the ACM, IRMA, ISACA, ISC2, ISSA, ISSEA, and is a senior member of the IEEE.