3.1. Access Control Scenario
The considered access control scenario consists of a set of severely constrained CDSs that publish some tiny services. These services on CDSs can be accessed by subjects through IP networks. These CDSs communicate at the link layer with a more powerful base station using specific protocols, such as IEEE 802.15.4 [
25], which covers short ranges and enables low bit rates. At the network layer, each CDS implements IPv6/6LoWPAN, enabling the establishment of IP communications with any device in the Internet without the need for intermediary proxies.
There are three basic actors in the access control scenario, as shown in
Figure 2: a
subject (1), constrained or not, which intends to access an either operational or management service as a
resource in a CDS (2), with the collaboration of a trusted third entity in the establishment of a security association, namely, an
ACS (3). This schema is aligned with the IoT reference stack [
26], where perception layer integrating CDS, and network layers are exploited by the application layer on the top, often through the corresponding graphical user interfaces.
The
subject endpoint, depicted as a sensor, a smartphone and a workstation, can be a constrained or less constrained endpoint, located in the related application datacenter, or behave as a less trusted mobile endpoint. Note that the term
subject is adopted as a logical entity, which is a running software or process, acting on behalf of an individual or a service in a machine-to-machine environment. This is a well-known term in access control related models and standards [
27,
28]. For clarity and uniformity purposes, subject term is used from now on in all aspects of access control model definition, and is equivalent to the client principal term adopted in some standards such as Kerberos [
29].
In a similar way, note that the term resource is adopted as a logical entity, which is a software component that provides data from or is used in the actuation on physical entities such as constrained devices acting as sensors or actuators. Resources typically have correspondent interfaces to interact with them. This is also a well-known term in access control related models and standards. For clarity and uniformity purposes, resource term is used from now on in all aspects of access control model definition, and is equivalent to the service principal and server terms adopted in related standards.
Explicitly, the proposed access control architecture consists of two parts: a standardized cross-domain access control central checkpoint as an initial mandatory filter, namely, the ACS, which is not resource constrained, and a distributed checkpoint in each CDS, which enables dynamic and fine-grained access control, based on local context as well as accounting. This proposed multi-step enforcement approach, which combines centralized and distributed access control architectures, adopts the benefits derived from each and makes E2E security both light and efficient in CDSs.
This ACS, which can be a powerful workstation or a cluster of servers using standard security and traditional access control standards and technologies, supports most resource-intensive features of the Hidra security protocol such as identity and credential management, cross-domain federated authentication, preliminary authorization, policy life cycle management and accounting. Furthermore, the ACS avoids a large number of unsuccessful message exchanges with the CDS when it refuses unauthorized access attempts, and this is a crucial point in terms of energy saving. Additionally, the ACS enables a unified and coherent policy management, which, on the one hand, is becoming a critical aspect in many fully distributed deployments and, on the other hand, reduces storage requirements in the CDS in open and flexible E2E scenarios. Moreover, when a positive preliminary authorization occurs in the ACS, it fetches, wraps, codifies and delivers the proper security policy to be enforced by the CDS based on the local context. The validity of the security policy is related to the security association establishment as well as any further access during its lifetime, and it might convey granting rules related to an individual request, a session, a work-flow etc. in any E2E secure interoperable use case. Moreover, the security policy can be refreshed during the security association lifetime by the ACS under any condition through the Hidra security protocol.
The CDS supports complementary security features such as authentication, security policy reception, secondary local-context-based authorization during security association establishment and lifetime, as well as tracking and accounting notifications. The scope of the feasibility assessment conveyed in this article is the experimental impact analysis on the performance of such features on the CDS that enable E2E dynamic, flexible and tight access control.
3.2. Authorization Policy Language and Codification
In this section, a specific expressive policy language is briefly presented. The goal of this policy language is to overcome the resource constraints of the CDSs when enabling the definition of fine-grained policies to be provisioned and enforced in the CDS to comply with the least privilege principle. This policy language definition enables both the granting of decisions based on local context conditions and reacting accordingly to the requests by the execution of additional tasks defined as obligations.
This policy language is declarative and adopts the deontic concepts of rights, prohibitions and obligations. It is inspired by non-constrained access control models, such as XACML, but it balances the expressiveness and feasibility in CDSs adopting and adapting just the core subset of definitions.
A security policy defined with this policy language is an optional set of rules that conveys the conditions to be checked and the derived reactions such as in the broadly adopted event-condition-action approaches. Specifically, this policy language determines a sequence of constructs with particular significance in the decision making and enforcement time. The number and meaning of the constructs in this proposal result from the compromise between expressiveness and performance. The order of the sequence becomes essential to its proper interpretation.
The elasticity of the policy is based on the definition of some constructs as mandatory but some others as optional. This design aspect enables the reduction of the length of the policy when a simple policy is sufficient. In addition, some constructs are extended through other nested constructs, where some of them can be instantiated many times within a container construct. Related to this elasticity feature, the more constructs instantiated, the higher the expressiveness of the policy, the more granular the policy is, and thus the tighter the enforcement is. Consequently, the challenge to overcome is to be feasible even in the most expressive use-case.
Specifically, the proposed policy language enables a security policy instantiation through the policy construct, with three nested constructs. First, a policy instance identification id is specified for logging, tracking and auditing purposes. Then, a default policy granting effect is specified. This effect will prevail in the case of an absence of rules or under any rule evaluation conflict. In the use cases where preliminary authorization enforced by the ACS and mutual authentication is sufficient, this effect construct is highly useful, and the resulting policy instance is the simplest and shortest instance. It also becomes very functional for notifying revocation and related security association finalization. Finally, optionally, an array of rules may be instantiated as a ruleset to define the conditions and related reactions. Each rule in the array is an extensible construct.
The representation of the policy construct in the Extended Backus-Naur Form (EBNF) notation is depicted in
Table 1. This EBNF representation shows hierarchical constructs to be defined along with expandable, nestable and repetitive constructs as needed.
Figure 3a also shows a graphical equivalent view, where optionality and contents are more clearly represented.
The
rule construct depicted in
Figure 3b is defined as a sequence of eight nested constructs, where the order is crucial. Some of them, such as
id,
effect, and
conditionset, are mandatory, and the remainder, namely
periodicity,
iteration,
resource,
action and
obligationset, are optional. The
conditionset and
obligationset are arrays of expressions and obligations, respectively. These repeatable and extensible
expression and
obligation constructs are defined in a similar manner, and they enable the instantiation of rich expressions on attributes declared as inputs as well as reactive tasks declared as obligations. This makes a big difference with currently implemented and researched authorization policy expressiveness and therefore tightness in constrained devices, which convey conditions simply as value matching on a set of attributes. Moreover, there are no constrained-device-oriented approaches supporting obligations, which are enablers of advanced features such as precise and instant logging, active accounting, system and process context updating, system blocking, transaction level control, and usage-based control. In addition, any granting decision on an operational activity can be first triggered and then tracked through rule
id,
effect,
resource and
action constructs. Finally, optional
periodicity and
iteration constructs expand the potential of the obligations.
Consequently, all these constructs nested in the main construct policy enable the instantiation of an expressive policy, and it is the purpose of this paper to assess the feasibility according to its performance impact. Moreover, any policy instance is defined in the ACS, provisioned to the CDS when a security association establishment is requested, and enforced before the establishment and during its lifetime in the positive authoritative case.
Likewise, this policy language can be used to define policy instances according to the most broadly implemented access control models (i.e., the RBAC and ABAC models). Any resulting policy instance is a text file that can be generated in several formats, edited by human administrators, and stored and processed by information systems.
The length of any policy instance, in a human-readable format, grows proportionally with the desired tightness, and this would impact the performance negatively. Moreover, the policy expressiveness of the proposed policy language would become useless if the length of the resulting instances was excessive. Therefore, a specific policy instance codification is defined, therein achieving a notable reduction in the length of the policy instances. Considering a policy instance defined according to the proposed policy language, the goal is to generate the minimum possible bit stream. This compression limits the impact of the length of policy instances on both storage and energy consumptions. The proposed codification distinguishes from existing codifications that serialize policy instances through standardized generalist solutions such as CBOR.
The proposed policy codification serializes each construct and concatenates them in a bit stream. The prior knowledge of the defined sequence of the constructs and their format is the cornerstone. An additional and crucial factor is the injection of some agreed-upon bit masks to specify both the existence or not of optional constructs and the number of elements in related arrays of nested constructs. This enables one to deal optimally with the elasticity defined in the policy language, therein avoiding unused but expected fields of expressive policies, which significantly shortens the length. Consequently, the compression ratios are higher than those resulting from currently available generalist approaches such as CBOR.
With respect to covered policy formats, this policy codification can easily be applied to any original textual policy instance format (XACML, JSON, etc.).
Moreover, the agreed-upon conventions can be parametrized for several application scenarios and domains, and the policy domain model (PDM) would be the set of adopted decisions, for example, on the length of the different arrays, the identifiers of functions, and labels. At implementation time, when the PDM is specified in a separate file, its patterning, versioning, modification, provisioning and activation are much more agile, thereby enabling an effective change management. To that end, the better abstraction and multi-domain applicability of the proposed access control model can be obtained, providing scalability and flexibility with the possibility of adjusting the policy expressiveness and scope to the use-case applications and domains.
Regardless, the described policy language and codification are specified in detail in [
7].
3.2.1. Resulting Policy Instance Review
When instantiating security policies ranging from simple use cases to highly critical cases, the lengths of the instance files increase progressively due to the elasticity enabled by the policy language. To illustrate such effects, four representative sample groups are conveyed hereinafter.
Sample 1 (S1): A policy with no rules comparable in expressiveness to traditional approaches broadly implemented and validated in C0 CDSs. This example might be the access granted to a subject initially authenticated and authorized in the ACS and then authenticated in the CDS.
Sample 2 (S2): A policy containing one rule with conditions, somewhat comparable in expressiveness to the recently researched DcapBAC approaches based on PKC and CBOR policy codifications, which have been validated in less-constrained devices (C2 CDSs). Certainly, the proposed approach under analysis enables rich expressions on attributes such as arithmetic, logical, textual, relational, and comparative, depending on the application domain, rather than only the simple matching of DcapBAC. For example, beyond initial authorization in the ACS and local authentication in the CDS, access for any maintenance action can be granted only after ensuring that the battery level exceeds a given threshold and not matches it.
Sample 3 (S3): A policy with one rule containing both conditions and obligations. This level of expressiveness is beyond any existing feasible solutions for constrained devices. For example, after checking a local condition, such as the battery status, any maintenance action shall be granted, and, additionally, the system status flag or semaphore is updated as a reaction enabled by obligations.
Sample 4 (S4): A policy with several rules containing conditions, obligations and periodic re-evaluation. This level of expressiveness is far beyond the capabilities of existing solutions. This example incrementally covers checking different conditions related to different actions on different resources. For example, it can enforce the checking of the system status attribute correlation before maintenance actions can occur and/or the checking of the attempts to perform any operation on the system before granting administration rights. Both conditions highlight its finer granularity. Additionally, each access may produce specific reactions through obligations such as updating system flags to enable transactional controls, updating counters to enable usage controls, or performing concrete remote notifications that enable instant awareness.
To summarize, these four sample groups (S1–S4), defined with a clarifying purpose, convey incremental expressiveness of the policy and therefore granularity and tightness at enforcement time. The four samples range from no rules to several rules to be enforced locally in the CDS, as summarized in
Table 2. It is also noted in which constrained platforms each sample range can be used based on currently feasible access control models. The proposed access control model is excluded, and once its feasibility is demonstrated, it would enable all samples in all C0-C2 platforms.
3.2.2. Measurable Policy Instance Examples
For such representative samples, the lengths of specific policy instances vary depending on the specific field values and iterations of the nested constructs that they include. For each of the four samples, exemplary Instances of Samples have been considered to calculate specific lengths.
The policy codification is specified by taking as exemplary input a JSON representation of any policy instance. JSON as an input format is considered appropriate because, on the one hand, it is a broadly adopted format of the payload in CoAP, the de-facto standard web transfer protocol specifically designed for constrained devices [
20,
30], and, on the other hand, its clarity, being simple and readable by humans.
Instance sample 1 (
): An example of a policy instance represented in JSON with no rules but rather a policy identifier and the granting effect for tracking purposes can be instantiated as shown in Listing 1.
The codification of such a policy instance results in a bit stream of 10 bits packed in two bytes: 0b0110010110.
Instance sample 2 (
): An example of a policy instance represented in JSON with one rule enclosing one condition on one input can be instantiated as shown in Listing 2.
Such a policy instance shown as a JSON text file is easily readable and manageable for humans. Its length is 164 bytes, but it is shorter in the following minimized JSON format, which is processed by systems.
{"id":102,"effect":"PERMIT","rules":[{"id":0,"effect":"DENY","conditions":[{"function":"isTrue","inputs":[{"type":"SYSTEM_REFERENCE","value":"onMaintenance"}]}]}]}
Moreover, such a serialized JSON file can even be further shortened if it is pre-processed by applying some semantic codes, as explained earlier in the policy domain concept. Thus, the length of the resulting optimized JSON file (JSON’) is 118 bytes, which is significantly shorter.
{"id":102,"effect":"1","rules":[{"id":0,"effect":"0","conditions":[{"function":"160","inputs":[{"type":"6","value":"255"}]}]}]}
Finally, the codification of such a policy instance results in a bit stream of 53 bits packed in 7 bytes.
Instance sample 3 (
): An example of a policy instance represented in JSON with one rule enclosing both one condition on one input and one obligation, which can be instantiated as shown in Listing 3.
Such a policy instance shown as a JSON text file (236 bytes) is shorter in a minimized JSON format and can be made even shorter if it is pre-processed by applying some semantic codes, as shown in earlier examples. Thus, the length of the resulting optimized JSON file (JSON’) is 174 bytes, which is significantly shorter.
The codification of such a policy instance results in a bit stream of 67 bits packed in 9 bytes.
Instance sample 4 (
): An example of a policy instance represented in JSON with two rules and periodic re-evaluation. The first rule contains one condition with no input and one obligation. The second rule contains three conditions on up to three inputs and one obligation. Such a policy instance can be instantiated as shown in Listing 4.
Such a policy instance shown as a JSON text file (798 bytes) is shorter in a minimized JSON format and can be made even shorter if it is pre-processed by applying some semantic codes, as shown in earlier examples. Thus, the length of the resulting optimized JSON file (JSON’) is 554 bytes, which is significantly shorter.
The codification of such a policy instance results in a bit stream of 258 bits packed in 32 bytes. This example is illustrative of the incremental effectiveness of the proposed codification.
The length of the policy instances grows significantly with the tightness of the enforcement.
Table 3 shows the detailed lengths of the four examples of sample instances previously presented (
) and their expressiveness in terms of enclosed constructs.
To assess the compression factor of the proposed codification, it is also pertinent to compare the resulting lengths with the existing representations and serializations of the policy instances. The exemplary sample instances (
) as represented in JSON and CBOR result in the lengths shown in
Table 4, where the authorization policy binary representation proposed in the access control model under the feasibility assessment is denoted by the Authorization Policy Binary Representation (APBR).
According to the resulting lengths shown in
Table 4, the JSON format policy instances, which are the de-facto standard adopted in CoAP, are excessively long in comparison. Furthermore, after pre-processing the JSON representation with identifiers and PDM-related semantic conventions, the resulting lengths are still excessive. The CBOR format results in shorter lengths than JSON, but they are still longer than the proposed approach because they are not optimized for policy specification and interpretation purposes. Consequently, the proposed policy codification, APBR, achieves the best compression factor. APBR is the shortest; therefore, it can be anticipated to produce the smallest impact on storage, transmission and processing.
3.3. Hidra Messaging Protocol
To efficiently convey the presented access control policies to the CDSs, the Hidra protocol is considered. Hidra, depicted in
Figure 4, is based on a three-party architecture and provides authentication and authorization in two steps: dynamic policy provisioning and accounting.
Hidra is based on Ladon [
24], which is a validated solution for C0 CDSs in the establishment of E2E security associations, through pair-wise keys, guaranteeing mutual authentication and very basic authorization (S1 and S2 samples) but lacking provisioning and accounting features.
Both Hidra and Ladon are based on symmetric key cryptography, and they assume that each endpoint possesses a secret key shared with the ACS. The operation is based on the use of tickets, a capability distributed by the ACS that contains a proof of the identity of the subject that requests it. Tickets are encrypted so that only the entities for which they are intended are able to decrypt them.
After a successful authentication in the ACS (Phase 1), the subject that wants to access a service in the CDS obtains a ticket granting ticket (TGT). This TGT is used by the subject to demonstrate the authentication to obtain resource tickets (Phase 2) required to access any resource on the CDSs.
This approach enables attribute-based access control (ABAC) authorization enforcement in two steps. In the first step, as a condition for releasing any resource ticket, fine-grained preliminary access control is performed in the ACS (Phase 2), focusing on the attributes of the subject, resource and expected actions. If this first authorization step is successful, the ACS sends a message to the subject including a resource ticket; it also sends a message to the CDS, which in addition to the session key with the subject conveys an expressive authorization policy instance. This particular instantaneous custom policy provisioning avoids the permanent storage of policies in the CDS and reduces network overhead compared with approaches enclosing the policy in the resource ticket. Typically, policies are enclosed in the resource ticket. However, such an approach implies increasing the length of the ticket, which is a long structure by itself and can result in packet fragmentation and thus additional network overload due to the short available payloads of IEEE 802.15.4 frames. Therefore, there is an advantage for the HID_CM_IND message, which is one of the smallest messages, to efficiently convey the access control policy to the CDS.
In the second authoritative step, once the subject has obtained a resource ticket, the local context-based access control is performed in the CDS (Phase 3). First, the proper rule is evaluated to make the granting decision, and, then, the corresponding reactive actions are enforced. In a positive authorization case, the security association is established, and the result is a shared session key to be used for future E2E resource access exchanges.
Another remarkable feature of Hidra is the addition of a pair of messages to enable precise accounting (Phase 4). With these messages, the CDS will provide notification of details, such as who performed what, where and when, in every access request received from the subject. These notifications are gathered, normalized, and treated properly by the ACS. Additionally, the ACS can react and send a related policy message, enabling the dynamic delegation, request, cancellation and revocation of permissions.
Then, although the security association is not finalized, the access control is enforced in the CDS autonomously in every future request attempt since the received expressive policy (Phase 2) includes related rules.
Consequently, the unified, coherent and adaptive management of the policies by the ACS is achieved. Additionally, the proposed Hidra protocol and the adopted architecture enable one to relay the most expensive features on the ACS, which entails the usage of standard security and access control technologies in non-constrained interactions. It also ensures that most unauthorized access attempts are refused before reaching the CDS, avoiding unsuccessful message exchanges and thus saving energy in the CDS, which is a crucial aspect.