OGC Testbed-16: Data Centric Security Engineering Report

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

Data-centric security (DCS) is an approach that underlines the security of the data itself rather than the security of communication infrastructure such as networks, servers, or applications. DCS further embeds security and usage policy within the content. The DCS related work previously conducted in the Testbed-15 explains the motivation for DCS in geospatial environment as "the response to the possibility that an unauthorized user, who intercepts network traffic or hacks systems storing sensitive information gains unauthorized data access".

Testbed-15 explored the DCS essentials and evaluated basis data centric protection (encryption), security labels (metadata), and access control based on security access policies. The policy enforcement considered temporal and spatial attributes assigned to requested data sets and service consumers. Testbed-16 adds the JSON encoding for responses and introduces a dedicated key management server component. Testbed-16 work further allows content negotiation via new, proposed media types. Other aspects of the DCS concept, such as management and tracking, might be subjects of the future work.

A data-centric security model includes:

According to established theoretical models DCS relies on the implementation of the following:

These concepts should be considered as a key aspect of the whole information life cycle phases such as creation, processing, collaboration, storage, archive, search, and finally deletion.

In a DCS architecture the data sets are "labeled" with metadata. This is usually in form of a structured header having attributes which specify their security relevance and allow the application of security access policies on such data (RFC-7444).

Security Labels provide a mechanism for controlling access to information in security environments. Data objects are labeled with a classification, such as "Confidential", "Secret", or "Top Secret". Data consumers are given a clearance, using the same scheme. The core model of security clearance (access control) is that someone accessing information has a security clearance, that controls what information can be accessed.

A common metadata format (DCS container structure) is the starting point from which more attributes could be integrated into the metadata. This includes for example, a creation and validity period, the data taxonomy, or the identity of the person assigning the classification. The data structure to hold this information should be designed in such a way that new attributes can easily be added. For example, the inclusion for post-release protection ensures the data can be released for a number of days, after which the data cannot be accessed. Cryptographic binding of the classification metadata to the data ensures integrity of the label and the data.

Document ITU-T X.841 (Security information objects for access control - Fig.5) provides general recommendation for DCS Access Control. Protected information is represented as a message with a cryptographically bounded (confidentiality) label. On the client-side policy enforcement makes data access decisions based on the label, user credentials (security level), and specific policy assertions about access granting. Comments in blue color added to the original figure represents the Testbed-16 DCS specific implementation details.

The most relevant part of a security (confidentiality) label is the classification. Many security label schemes (like those used in the previous Testbed-15 and in this one) use the following classifications:

STANAG 4774/8 standards define the application of a confidentiality label. This is a structured representation of the sensitivity of a piece of information. Previous DCS work was primarily focused on exploring that aspect of DCS. A data originator security label example based on NATO STANAG 4774 is given in the listing below. Encoding is XML. Bound through cryptographic signature with an arbitrary data payload, for example a Geography Markup Language (GML) document, would label the document as "secret".

Although the task dedicated to the DCS did not mandate formal requirements in Testbed-16, this section lists informal requirements based on the OGC Testbed-16 Call for Participation (CFP) as well as the section Future Work from previous Testbed Engineering Reports.

Testbed-16 DCS Requirements

For this Testbed, the experiments advanced the DCS concept (with respect to the geospatial domain) to a high-level architecture similar to "Digital Rights Management" or DRM. DRM concepts allow for the creation, protection, and delivery/consumption of content in accordance with contracts put in place between the parties. Such contracts specify which content is available against predefined conditions, usually specified in a policy. DRM architectures make clear the distinctions between content author, owner, providers and consumers. Using a DRM platform, a client could order content. This content could be multimedia more relevant to this topic than geospatial data sets in GML or satellite imagery data. After receiving a payment or obtaining credentials elsewhere the service/client streams and encodes/consumes the content on the fly or downloads and encodes/consumes the content later (possibly several times during the key validity period). With inspiration from a DRM architecture, the Testbed experiments derived use case scenarios and specified component interactions.

An example of more detailed evaluation of DRM in the geospatial area could be seen in GeoDRM RM.

This motivation and the requirements put on DCS lead us to the following two use case scenarios:

Because the DCS protected data sets leave the security perimeter of the data owner and are hosted in a cloud and/or distributed via third party channels, the important elements to deal with when applying the concepts of data-centric security are the strength of the encryption key (the length of the key) and cipher algorithm for performing encryption/decryption. These factors (strength and algorithm) relate to the differences in how these scenarios use the data. While the Online Streaming of protected content requires the decryption on the fly, in the case of Offline Authorization the client caches the encrypted content. The client decrypts the content when needed in the offline scenario.

The next figure depicts a high-level TB-16 DCS architecture with respect to the more general DRM architecture as depicted on Figure 2 and used as template:

The figure represents a logical view, which roughly mimics the general DRM blueprint. The implementations are different for desktop and mobile scenarios. In the desktop scenario a DCS server provides protected content on request via an OGC compatible API. An encoder component is implemented inside the DCS service and it is basically irrelevant for this testbed. Mobile scenario on the other side puts the focus on the policy enforcement, decoding and visualizing of protected content on mobile devices with respect to the user rights and policies associated with data sets. Therefore, the function of the encoder was performed by an external tool, which was used to prepare the content for TIE execution. Protected content resides in a cache on a mobile device. The mobile scenario demonstrates the interaction with KMS and content visualization on a mobile device after decryption was performed in accordance with user roles (security levels) and (GeoXACML) policies in the GeoPEP component.

The following components, listed with their essential features, are part of the Testbed-16 DCS architecture (in both scenarios):

Information security can be applied either on the infrastructure (perimeter-security) or in a data-centric fashion. While infrastructure/transport oriented security standards are integrated in communication infrastructure like in TLS 1.3, DCS is fully independent from the underlying communication infrastructure. This is important because (in many security critical applications) the stakeholders cannot rely on the security provided by communication channels (like TLS). With other words, data owners need to remain in charge of data securing when they are distributed in cloud-based resource services. Thus, it appears reasonable to incorporate security concepts in the data sets, which urges expanding the existing data structures for additional elements to carry encrypted data and artefacts such as metadata, security labels, signatures, etc.

In protocols with application-layer intermediaries, channel-based security protocols protect messages from attackers between intermediaries, but not from the intermediaries themselves (not from, for example, malicious applications running on the platforms of intermediaries). These cases require object-based security technologies, which embed application data within a secure object that can be safely handled by untrusted entities as it was described for JSON encoding format (RFC 7165). Data-centric security advocates generation, storing and provision of security related metadata and content such as security tokens (digital identities), policies, keys, signatures, encrypted content and schemas.

In the geospatial domain, data centric security is applied on data encoded using geospatial domain specific grammars (schemas) such as GML or GeoJSON. GML is an XML encoding while the GeoJSON format is encoded in JSON. The previous work in Testbed-15 regarding the DCS was based on GML and the container structure required for DCS was encoded using STANAG 4774/8 and XML binding.

JSON (JavaScript Object Notation) is a well-known XML alternative and widely used data-interchange format. GeoJSON was created as a response to the popularity of JSON encoding format and as an alternative to previously established GML format based on XML and XML Schema. GeoJSON defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents. RFC 7946 is the current GeoJSON standard.

Additionally to new DCS container formats, new HTTP Accept header content types are proposed for content negotiation. The Accept request HTTP header advertises which content types (container formats) the client is able to understand, which is important for interoperability.

If the security is required to be applied in the data-centric fashion, an additional data structure needs to carry signature and encryption artefacts. This includes the metadata related to a data origin identity, access rights/policies, and optionally data structure/taxonomy. Two encoding options for data centric securing of (geospatial) content are available. These are XML-GML and GeoJSON based encoding standards with corresponding containers. Two set of standards, NATO STANAG 4774 and STANAG 4778 (short STANAG 4774/8) and JWT/JOSE were chosen to implement the required container structure. Additional DCS containers and encodings require new media types to describe all useful combinations of data/container encoding and applied security functions.

To enable data exchange and interoperability among NATO Member States, NATO STANAG 4774 and 4778 define a syntax (4774) for trusted security labels / markings and how these are cryptographically bound to data objects (4778) to ensure the integrity of data and the label. Trusted security labels include, for example, data on the creator, creation and expiration date. There are different profiles for REST, SMTP, or SOAP, XMPP or Office Open XML. JSON binding is not supported.

Beside standard security labels like classification, creator or creation and expiration date, in the geospatial domain additional metadata about the spatial scope of the data set is frequently relevant. For example, large, encrypted sets of geographic entities having metadata labels containing a bounding box allow access policies, which constrain data usage based on user location.

For JSON encoded data mostly used in interactions via RESTful APIs there is a family of standards designed to implement confidentiality and integrity in a data centric fashion. These standards are based on JSON Web Token (JWT) and also includes the JWE and JWS specifications, which is known as JOSE. JWT is basically seen as the root specification, which the JWE and JWS were derived from.

STANAG 4774/8 was used to implement the Testbed-15 DCS architecture with trusted security labels. Currently, the standard fully supports XML binding. Other representations, for example in JSON, would be possible (JSON is currently not supported). The full STANAG 4774/8 data structure is depicted in the following figure:

The figure displays the container structure from testbed-15, which holds a key (symmetric) required for data decryption. The key is protected inside of the encrypted metadata section and can be extracted only if it were encrypted with the receiver’s public key, which means the encryption was performed using public cryptography (PKI). This approach has certain security limitations and inflexibility. In Testbed-16 that will be mitigated through a new component - the KMS responsible to issue decryption keys on request (for a given key_id encoded in a DCS container). Instead of encrypted keys, their identifiers (key_id) originating from the KMS will be placed in DCS containers.

Despite the fact that only XML binding specifications were provided for STANAG 4774/8 so far, there is another, (from the interoperability point of view) useful option - to introduce an equivalent binding in JSON for clients, services and APIs based on that technology. In such a scenario, JWS (encryption) and JWT (signature) standards (also called JOSE) are used instead of JSON-encoded STANAG 4778 content to ensure the integrity of the payload and security label, while STANAG 4774 will provide a blueprint for security label information and other meta-data of interests.

In the JavaScript/JSON ecosystem the communication is secured on a data level by applying a set of standards such as JWT and JOSE (combination of encryption and signature via JWS and JWE). The standards provide a structure intended to capture the metadata and artefacts required for standard security functions such as confidentiality and integrity. The following table gives an overview of the security stack based on JWT and JOSE:

A JSON security stack built around the standards listed above visualizes the relations between standards. While everything is encoded in JSON, JWE and JWS represent standard cryptographic operations related to encryption and signing while JWT deals with digital identities.

When Object Signing and/or Encryption (JOSE) is used to protect a payload, the resulting structure (as depicted on the figure below) establishes a type of container holding both the payload and the metadata. While JWS requires a fairly simple format to ensure the integrity, JWE requires additional attributes to support the confidentiality through the encryption. The payload could be any geospatial content, for example GeoJSON. The figure represents the container encoding with comma separated sections. An alternative would be to use a full, slightly more complex JSON representation.

For JWS the payload is first signed and enclosed in a data structure defined in RFC 7515. The structure has:

The header containing the signature metadata, the payload holds the base64 encoded protected content and the signature ensures integrity (or that header and payload are cryptographically bound to each other). The payload segment might also enclose the additional metadata information.

If the confidentiality of data is required, the plaintext data can be encrypted and wrapped up in a container structure based on JWE (RFC 7516). The container will have the structure according to the specification containing the following parts:

Ciphertext is the section where encrypted data payload (created out of original payload plaintext) is placed. Other segments such as initialization vector or authentication tag are populated according to the specification and in order to support data integrity.

The information to protect remains encoded following STANAG 4774/8 but in JSON (binding). The JOSE would provide additional cryptographic protection (ensuring integrity) for such a DCS container in JSON encoding. Following are the possible container forms or the combination of "JOSE for security implementation" and "STANAG to encode the meta-data":

The options are depicted in the following three figures. The green bar represents the overall information (data-centric container with all protection measures). Metadata as shown here is STANAG encoded in JSON:

There are a variety of approaches to implementing the content negotiation as described in (RFC 7231) for a RESTful API. Two common options are:

However, both of these non-HTTP content negotiation examples violate the rule saying that a REST API should not "include artificial extensions in URIs to indicate the format of a message’s entity body". Instead, they should rely on the media type, as communicated through the Content-Type header, to determine how to process the body’s content.

The proper way for content negotiation is to specify the content type of an HTTP response as a parameter of the media type in the HTTP request. This is the option that is selected here for DCS. This method avoids changing URIs and makes use of an existing HTTP header rather than creating a custom one. A Media Type describes the content of an HTTP request or response such that the service provider knows how to handle the request. In short, service requests use media types in order to notify the service (content provider with DCS) which combination of encoding and container structure is required.

When a client issues an HTTP request, it can indicate what media types the client would prefer to receive by using the Accept HTTP header. For example, GeoJSON has a (generic) media type "application/geo+json" for all resources. In order to support different encodings and DCS containers, media types need to be defined, such as application/gml+stanag.

How many different media types are needed to cover all useful type options for responses? The following list presents the encodings and container structures that appear to be useful in the context of this testbed:

Not all possible combinations for encoding and content types as listed here make sense or are useful. First of all, the assumption is a STANAG 4774/8 container structure is taxonomy for DCS container structure. New supported encoding will be provided in JSON. When the content is encoded in JSON, using JWS and JWE "containers" for singing and/or encrypting appears to be the choice. JWS is used to ensure the integrity. Otherwise, XML encoded GML content is enclosed in the container based on the STANAG 4774/8 binding for XML. XML Signature (XML Signature defines an XML syntax for digital signatures) is used to ensure the integrity. The figure below provides an example depicting several options for content negotiation:

Another aspect of HTTP content negotiation, which introduces fine grained control over the response formats is related to the possible use of a Media Type parameter "profile" in HTTP header. As described in a W3C Working Draft Content Negotiation by Profile, clients may negotiate for content provided by servers based on so called "data profiles" to which the content conforms. This is "distinct from negotiating by Media Type or Language: a profile may specify the content of information returned, which may be a subset of the information the responding server has about the requested resource, and may be structured in a specific way to meet interoperability requirements of a community of practice". An Application Profile bundles several specifications and possibly adds additional requirements on an implementation. Extra requirements can be interpreted either as additions or as constraints. For the Testbed-16 case, the media type could be used to specify required serialization such as XML, JSON, GML, GeoJSON, while profile parameter could be used to further differentiate between different DCS container options (STANAG 4774/8, JOSE).

Following profiles are useful to refine the content negotiation in DCS:

Since the Accept header can contain multiple media types, clients can set alternative profiles and media types in the HTTP header for specific DCS protected geospatial content. Besides new media types to set this preference, the q parameter (relative quality factor) is used. The value of a q parameter can be from 0 to 1. 0 represents the least preferred while 1 is the most preferred choice.

Finally, DCS media types and profile parameters for content negotiation as proposed for XML and JSON encoded content are listed in these tables:

Testbed-16 demonstrated content negotiation and data retrieval with the following container/encoding variants:

Examples for content types (HTTP GET) are and DCS containers are given in Appendix Engineering Aspects for D120 and D145 under Requesting encrypted data.

The addition of a new feature to a feature collection has ramifications in a Data Centric Approach. Should the client or server perform the encryption? Which Key Management Service will handle the creation of keys and encryption of the content? Do the individual contributors sign the content? If the client encrypts/signs the content, how do servers support queries on the content? All these questions and perhaps more require some investigation and experimentation to determine how the creation of features fits the Data Centric Security Concept.

This activity could include the investigation of the specification of existing/new APIs for key management to enable standardization of CRUD for cryptographic keys within and outside of federated environments. Focusing on access control, an experiment could investigate how to control key creation and release depending on location of the user, the resource or both.

The protection of large data sets requiring keys for each item create situations producing/retrieving thousands of keys and encrypting thousands of items takes too long. The mitigation of the performance problem might involve tweaking a KMS API to support asynchronous key management and/or by optimizing the data securing process. For example, the API may support the bulk creation of keys. Perhaps a hybrid approach to DCS/KMS API could provide an API that is DCS aware and will make JWE and JWS data structures as part of the response. Such an API could provide enhancements over the classical approach to KMS APIs which is just concerned with key creation, encryption and signing as standalone activities that require the client to put together the DCS response.

Federated security enables collaboration across multiple systems, networks, and organizations in different trust realms. On the other side, DCS enables securing the data sets independent of the communication and computation infrastructure. Future work in this area might investigate options for data centric secured information exchange in a federation environment with federated key management systems, identity servers, and other security infrastructure. Technologies such as Blockchain might be useful to establish a federated network of identity providers and services.

In addition to current DCS approaches wrapping metadata keys and payloads into containers, future investigation may consider adding data such as policies, manifests, etc. to the package. This is important in mobile scenarios dealing with offline content.

Future work should consider adding DCS approaches to binary data. The experiments in the testbeds to date focus on feature data types. However, in geographic realms, feature data is a small part of the overall amount of data available. Future work should investigate how to incorporate DCS container or to modify the existing formats to support DCS concepts. For example, JPEG 2000 (JP2) is an image compression standard and coding system. Perhaps the format can be expanded to support encryption and metadata for classification into JP2 payloads. JPEG 2000 images using the OGC GML in JPEG 2000 (GMLJP2) standard and other gridded coverage data holding geospatial content for imagery could add DCS concept for integrity and confidentiality.

Applications and professionals use many more binary data formats today in addition to the JPEG standard. Future work should consider the full spectrum of data types available. This would include GeoTIFF, TIFF, Mr. SID, etc. Future work should look at other binary packaging formats and how to extend them to support Data Centric Security concepts. GeoPackage is one example of a binary container format that future work could extend to include encryption, integrity and confidentiality.

Future work should consider further development of the DCS Roles concept, as detailed in Appendix E: Roles. The core thrust may proceed in two simultaneous directions.

First, future work should incorporate more specific examples / target sample data files of scenario classifications, clearances, and feature data.

Second (and in parallel), the Roles concept should be transformed to be more generic / less specific to the NATO clearance/classification concept (while still supporting it fully and robustly). This would be done so it could be applied to more generic commercial, industry and consumer domains, allowing for the expansion of DCS utilization, which in turn helps the original sponsors have greater long-term capabilities.

This set of TIEs summarize the result when executing the implementation for scenario one with desktop client.

To determine the relevant TIEs, let’s take a look at the interactions between the components D121 (client), D120 (DCS Server) and D145 (Key Management Server). The figure below helps to identify the interactions.

(A) Defines the interactions between D121 (the DCS client) and D120 (the DCS Server). (B) Defines the interactions between the DCS Server (D120) and the Key Management Server (D145) and finally between D121 and D145.

This set of TIEs summarize the result when executing the scenarios for mobile client implementation. The TIE results show interactions between two mobile clients with a policy enforcement module (Android [Maxar] and iOS [Keys]) and a Key Management Service [Helyx]. The experiment did not have time to perform TIEs for data interoperability between the two mobile clients.

The following chart shows the results of the mobile client interactions with the various KMS functions.

The architecture illustrated in Figure 20 reflects the use case requirements for the desktop / server use case as outlined in the CFP: A desktop application (i.e. QGIS DCS plugin) can request NATO STANAG 4778 encoded responses where the data and the metadata is encrypted. For Testbed-16, the response structure is encoded in JSON mimicking NATO STANAG 4778 and 4774. The response contains an identifier for the cipher used to encrypt the meta- and data. When parsing the response in the DCS client, the cipher keys are fetched from the Key Management Server.

To ensure that a cipher key that is used by the DCS Server used to encrypt the meta- and data can only be obtained by a legitimate client / user, access tokens are used. The Authorization Server provides the capability for creating and verifying access tokens. The use of access tokens that are obtained by the DCS client and used with the DCS Server and Key Management Server ensure the sharing of a security context among all components.

Leveraging as many components from Testbed-15 as possible, the Testbed-16 architecture is comprised of only one new component: The Key Management Server. Albeit, the DCS Server is extended by processing JSON encoding.

The following sequence of interactions explain the overall co-play of the components:

The key_id from the response is included in the DCS Server response.

With the cipher key received from the Key Management Server, the DCS client is able to decrypt the meta- and data received from the DCS Server in (2).

The DCS client is implemented as a QGIS DCS plugin available from https://github.com/ogc-leedahl/QGIS/tree/OGC_Testbed_16

The following components build the DCS Server https://ogc.secure-dimensions.com/dcs

The Key Management Server is a PHP application hosted on https://ogc.secure-dimensions.com/kms/api

Applying encryption to achieve confidentiality does only make sense if it can be ensured that the cipher key can be protected against unauthorized disclosure. In Testbed-15, the protection of the cipher key was ensured by establishing a PKI for the users. The cipher key was encrypted with the public key of the user. The implication to this approach was that a cipher key is tied to a single user. It is not possible for software to process the encrypted data on behalf of the user. Or, for a user to pass the encrypted content to another user.

The more flexible key management in Testbed-16 demonstrates the concept where the cipher key is not included in a service response; rather the key identifier is included. This provides the ability to use and re-use cipher keys and modify the audience: which clients and users can fetch the key. But, the down side is that a Key Management Server must be designed that its flexible enough to support particular use cases but also ensure that a cipher key can only be obtained from an authorized user / application.

Studying the architecture from figure Figure 20 outlines that the DCS client is making an OGC API Features request where the response contains encrypted (meta)data and the keys must be obtained from the Key Management Server. This leads to a triangle of trust relationship: A security context must be exchanged between the components where the DCS Server is a kind of man in the middle between the client and key management server. So, the critical question is how to ensure that a key created by the DCS Server can only be fetched (and modified) by the original actor; the DCS Server is acting on behalf of the user / client when it comes to cipher key registration.

The base for protecting cipher keys, implemented into the Testbed-16 Key Management Server, is based on the concepts of RFC 7636 Proof Key for Code Exchange by OAuth Public Clients. The basic concept - as illustrated in the following figure - is that the client includes a code_challenge (either created by itself or provided by the user as a kind of private secret) with the request which is a hash of a private secret. When relevant in a later request, the client sends the private secret using the code_verifier parameter. The server can then compare the values sent first with the hash (assuming method S256 was used) of the plain sent with the current request.

The adopted protocol for the Testbed-16 architecture is illustrated in the following figure.

The use of the key_challenge parameter in request (A) allows the Client to request the cipher key from the Key Management Server adding the key_verifier parameter to the request (C).

The use of this protocol also enables the modification of the key by the original actor, as only the user / client is capable of adding the matching key_verifier to the request. The DCS Server or any other intermediary service is not able to provide or guess the private secret, as in the request (A) only the hash was submitted. It is therefore possible (but not implemented) that the user extends the audience for an encryption key that was created on his behalf (request). This would allow the user to share the received encrypted content with another user / client. The Key Management server would just need to implement the appropriate methods. Proof of authorization to modify an existing key can be based on the key_verifier.

However, the deletion of a cipher key is implemented, and that requires the caller to provide the key_verifier with the request to demonstrate ownership.

The implementation of the interfaces (API) and the functionalities for the Key Management Server is based on the requirements derived from the desktop / server use case. Two different interface categories exist:

All requests to the Key Management Server require a valid access token submitted via the HTTP header Authorization as described in RFC 6750.

The Data Centric Security Server implemented for Testbed-16 is an extension to the Testbed-15 implementation:

As for Testbed-15, the OGC API Features is leveraged on a typical Geoserver data set. In order to demonstrate the ability that the cipher keys change with the classification level of the data objects, the following fictitious classification for the Geoserver standard data set is assumed:

To access the protected data (feature types) four different users are available with different clearance:

When following Access the data, the feature types from above are marked (protected) and a click on the feature type triggers the login via the Authorization Server (AUTHENIX).

After searching for the login organization OGC the login via the OGC Testbed IdP is required (login via another provider will not return encrypted responses).

After a successful login with one of the users above and the password secret, the protected data is displayed in the preview mode. The links in the top right corner provide access to the NATO STANAG encrypted responses.

The DCS Server and the Key Management Server implemented for Testbed-16 demonstrate the ability to encrypt geospatial data and metadata separately as denoted in NATO STANAG 4778. The implementation illustrates the use of OGC API Features returning STANAG 4778 and 4774 encrypted data in XML and JSON encoding. Data is encrypted from a clear data source (Geoserver default data) with different cipher key strength, depending on the fictitious classification label of the feature type. The cipher keys created by the DCS Server can be obtained with the client application via the key identifier. Access control at the Key Management Server ensures that only a legitimate user / client combination can fetch the cipher key to decrypt the data or to delete (inactivate) a cipher key.

The Key Management Server supports encrypted responses to ensure data centric security at the highest level. This requires the use of public keys that can be registered by a user, client or the DCS server.

To ensure that all components (client, DCS server and Key Management Server) are able to share a common security context, Bearer access tokens are used from a common Authorization Server as defined in RFC 6750. The use of OAuth2 and OpenID Connect interfaces ensure an easy-to-use API as many SDKs exist in various programming languages.

Helyx decided to take an existing standard for key management services as a starting point for the implementation of a KMS for DCS. Given the likely scenarios where DCS systems may be implemented, it was felt that basing the KMS on an implementation of the OASIS Key Management Interoperability Protocol (KMIP) Specification 2.x was of particular interest, given the strong protection for keys afforded by KMIP-compliant Servers. KMIP defines standard interfaces for both clients and servers and categorizes them in terms of basic and advanced cryptographic clients and servers. As this is a research task, a hardware KMIP server was not available to the team, so a software implementation in the form of PyKMIP Server was selected as the back-end key management server with a database.

As well as providing a Server module, PyKMIP also provides a Client module that simplifies the interactions with a KMIP Server. Client and Server communications are protected using mutually authenticated TLS. This client is used as part of a Python Flask application that uses the Connexion framework that handles HTTP requests based on OpenAPI Specification of the API described in YAML format. Connexion maps the endpoints to our underlying Python functions; this is preferable to other tools that generate the specification based on the underlying Python code. Connexion also validates requests and endpoint parameters automatically, based on the specification, and supports API versioning as well as providing a Web Swagger Console UI.

The implementation of the interface and functionality for the KMS is based on the requirements derived from the mobile / server use case. A number of different interface categories exist:

The implementation of an OpenAPI compliant interface to interact with a KMIP Server was largely successful and provided a number of useful insights into how a KMS to support OGC APIs may be integrated into such a service in the future.

At the start of the Testbed, the architecture was intended to be close to mirroring the KMIP endpoints, in order to provide as much flexibility as possible to the client implementations. During the course of the Testbed, there was significant thought put into how a KMS might interact with a DCS client, including the standards used for encoding keys, encrypted data and signing data. These ideas were not known at the time the decision was made on what the API might look like. As a result, this implementation of the KMS is quite different to that implemented in D145.

Whilst it has great flexibility it also poses some challenges especially in the offline scenario: the interface is relatively chatty, requiring a number of separate calls to the API to create a key, encrypt data, MAC data, sign data and then retrieve a key; this is just for one data item. This is required to be repeated for as many data items that exist and undertaking this via a RESTful interface can take long time. There are a number of potential approaches for dealing with this, such as:

In addition, it does not currently provide endpoints that allow a client to request a JWE or a JWS directly, which would be useful to the clients as they have been implemented with these standards in mind, which were not envisaged at the start of the Testbed. The KMS implements a content-type within the request of application/json though it may be that alternative content-types could be considered that modify the response according to their needs, for example application/jose+json.

A fundamental underpinning capability of KMIP-compliant servers is its support for KMIP operation policies that provide access controls over keys and operations on them. An operation policy is a set of permissions, indexed by object type and operation. For any KMIP object type and operation pair, the policy defines who is allowed to conduct the operation on the object type. In the current implementation, all operations are permitted by all users. However, if KMIP is to be used in the future, consideration needs to be given to whether and how these policies align with (Geo)XACML policies used to protect the data itself and how they might be kept up to date. This is additionally complicated by the fact that the Flask web service that provides the RESTful API uses its own mutual authentication with the KMIP Server; there is currently no capability to provide "on behalf of" operations. It is possible that when a client is registered to the KMS, it could also register a keypair with the KMS that is then also registered for authentication with the KMIP server and the KMS dynamically switches its authentication keys based on the client. Otherwise, it may also be possible for the KMS to provide its own authorization that could be linked to a PDP.

As PyKMIP is a software implementation that is not designed to be used in production, it does not provide all key variants and encryption options that are available in a commercial implementation. For example, it is not currently able to encrypt using an RSA key. Further development of the KMS may require changes to the PyKMIP implementation or workarounds to emulate the KMIP functionality within the KMS itself.

The KMS also has some of its own limitations due to the constraints of time and the focus on particular features required of the client. These include:

This annex introduces the engineering aspects of the policy decision and enforcement points and the policy documents used to specify the rules of access to DCS protected content.

Two implementations for desktop client and mobile clients uses different policy enforcement techniques for access control. In both cases we consider temporal and spatial aspects of access control as well as a role-based security classification.

The DCS Server in the desktop/client scenario has the functionality to dynamically construct NATO STANAG compliant responses from an OGC API Features backend service using XML or JSON encodings. This DCS functionality is realized in two modules, as illustrated in Figure 20: The GeoPEP and the GeoPDP.

According to the "Data Flow Model" of the XACML 3 standard (Data-flow diagram - Figure 1)[http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html], the GeoPEP implements the PEP, the context handler and the obligation service. According to the (Figure 3 - Policy language model)[http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html], an Authorization Decision sent from the PDP to the PEP can contain a set of obligations (0..1 ObligationExpression). The PEP processes each obligation which can be used to activate specific processing. When it comes to control the GeoPEP for achieving the DCS processing goals for this testbed, specific obligations are leveraged:

In addition to the data response obligations listed above, the GeoPEP can also be instrumented to modify the incoming request before sending it to the backend service. The relevant obligations to achieve that request rewriting are:

To explain how the policy controls the GeoPEP processing for the desktop/client use case, the GeoXACML policy is illustrated using ALFA.

As illustrated in Figure 54 the policy consists of a PolicySet and individual policies that apply to specific circumstances. The urn:secd:policy:tb16:request-policy:format policy evaluates decisions based on the request HTTP ACCEPT header. The urn:secd:policy:tb16:request-policy:location policy ensures that users in a particular location have elevated access. The urn:secd:policy:tb16:*-policy policies apply to particular data processing requirements.

Important in the policy above is the involvement of the responseJSON obligation attached to the PERMIT response.

Examining the Obligations from the policy explain naturally how the GeoPEP converts XML backend to NATO STANAG 4778:

The Testbed-16 DCS scenario for the mobile client was defined as the following:

Multiple mobile implementations were created to explore how to address the goals of this scenario, some of which include the concept of "DCS Roles".

Within the Mobile Scenario, an individual DCS Role is either the clearance/security authorizations for a specific person, or a generic clearance for a group of people (as defined by an administrator) - a member of the "intended audience" with whom the primary user wishes to share critical information without exposing sensitive information.

The following is an example implementation of the mobile client displaying DCS Role selection on a user device, as well as the filtering of different features by clearance as represented by DCS Role.