OGC Testbed-16: Data Centric Security Engineering Report

The OGC Testbed-16 Data Centric Security Engineering Report (ER) continues the evaluation of a data-centric security (DCS) approach in a geospatial environment. In order to fully explore the potential of the DCS concept, this ER first specifies two advanced use case scenarios: Data Streaming and Offline Authorization for querying and consuming protected geospatial content. The ER then specifies the communication with a new architectural component called the Key Management Server (KMS) via an Application Programming Interface (API) created for this Testbed. The API was invoked to register keys used to encrypt data-centric protected content. Then clients called the same API to obtain those keys to perform the data verification/decryption.

The document evaluates options for structuring and encoding of containers and payloads capable of carrying the secured geospatial data sets. Previously utilized DCS container based on the tandem of formats NATO STANAG 4778 "Information on standard Metadata Binding" and NATO STANAG 4774 "Confidentiality Metadata Label Syntax" are alternatively encoded using JSON and JavaScript Object Signing and Encryption (JOSE) security standard. Thus, DCS architecture supports several content representations for enhanced interoperability. The determination of the best suited data representation occurs via Access HTTP header set by the client, which is one of the standard ways of negotiating a specific kind of resource. This header describes the preferred choice of the client. To support this mechanism, this engineering report proposes several new MIME types for geospatial, DCS specific content negotiation.

OGC members can derive business value from this ER in the following areas:

The motivation for DCS is the possibility of preventing unauthorized access to systems storing sensitive data. Such systems could be increasingly popular cloud-based data storage solutions. When looking at drafting OGC standards such as OGC API - Features in a DCS scenario, standards need to include ways to classify the security requirements around data access. This classification (security label) can be performed through metadata fields as already evaluated in the OGC Testbed-15. A fundamental requirement for DCS is that the data is always protected, until an authorized actor makes use of the data. Additional requirements include the need for representation of the source of the information, as well as an assurance that the information has not been tampered with.

DCS protected data could be stored locally at the client location in order to be used within the validity period of time. As the data could pass through systems that do not belong to the data consumer nor the producer, the data must remain protected throughout all infrastructure that handles the geospatial data.

Another important aspect of the DCS is interoperability. In order to create, distribute, and consume the protected data set in an interoperable fashion, specifying the structures to encode the metadata, the protected contents, as well as the other related artefacts such as data access policies is very important.

The Testbed-16 findings show that it is possible to support DCS within an OGC API - Features implementation and have the API instance request the DCS protected content to be delivered in required encoding and DCS container format type. Storing the protected content on a mobile device locally and then decrypting and using the content offline and on demand during a possibly longer period of time is possible. Requesting the protected content online and having it delivered in a streamed fashion for a single consumption is also possible.

In support of the Testbed DCS experimentation, two scenarios were defined:

The first scenario anticipates immediate decryption and consumption of protected content. The key used for encryption is allowed to have lower strength of the encryption: Shorter key = less computational power required to encrypt/decrypt the content. The cypher (an algorithm for performing encryption or decryption) could also be simpler and therefore more efficient. The content owner wants to keep the full control over the protected content. The purpose of the encryption is to mitigate the risk of a possibly unsecured underlying network infrastructure. The content provider (DCS service) creates keys to encrypt requested content on a synchronous request/response basis. The key created by the DCS service gets registered to the KMS and could be retrieved only within its expiration time. The client is not supposed to permanently store encrypted data locally (on a desktop client). Even if the client would try to do that, due to the very short expiration time the referenced key cannot be obtained for such purpose.

The second scenario assumes the clients operate in an offline mode disconnected from the network where the DCS service is located. Protected data required for a "mission" are supposed to be downloaded and stored locally for later (field) use, possibly over a longer period of time. This scenario requires stronger security. As such, the keys are issued with an expiration time. The policies associated with issued keys contain additional geospatial assertions, which limit access rights based on user roles.

For both scenarios an OGC API - Features and DCS compatible service endpoint needs to be aware of the required encoding and the container format. Because one of the requirements for this Testbed activity was to provide support for several encoding and DCS container types, it is important to put the code for the required format in the request. A container format is a data structure which contains encrypted portions of sensitive data and associated metadata. To specify the required response formats several new media types are defined to be used as part of service requests. That includes encodings and standards such as XML, JSON, STANAG 4774/8 and JOSE.

A challenge, especially for the anticipated high grade of interoperability, was related to the absence of the support for either STANAG 4774/8 output format based on JSON encoding or any other structure/format besides the traditional XML encoding in the previous DCS architecture. The STANAG 4774/8 output format is a container format that contains signed and encrypted portions of sensitive data and associated security labels or the metadata. The Testbed participants specified and demonstrated implementations for multiple encoding options and documented recommendations regarding encodings and container formats (STANAG, JOSE).

Another design and implementation challenge was related to the Key Management Service. In the Testbed-16 architecture the KMS is responsible for creating, registering, invalidating and issuing cryptographic keys with selected strength and expiration time. The keys are used to perform cryptographic functions, including authentication, authorization and encryption. The KMS allows separation of DCS protected content from cryptographic material (keys) required for the consumption, which was not the case in Testbed-15. For Testbed-16 the new KMS components implement an OASIS API called KIMP designed to support the key management functions. In case of large data sets, where each entity is protected by a dedicated key, large key sets are required. In such situations, with many thousand keys required, key generation and retrieval takes too long. The slow responses from the KMS is caused by computational intensive key generation and might be mitigated by extending the API and optimize the data securing process.

Future testbeds should investigate following topics:

The following normative documents are referenced in this document.

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

Chapter 6 introduces the problem of geospatial data centric security with respect to advanced use case scenarios derived from the digital rights management architecture.

Chapter 7 lists informal requirements and presents two advanced use case scenarios. These scenarios include content negotiation, retrieval, decryption, and the portrayal of data centric secured geospatial data sets on desktop and mobile devices. This chapter also depicts some aspects of Testbed-16’s solution/demonstration architecture.

Chapter 8 discusses payload encoding standards, data-centric container structures, and MIME media types. The chapter presents options for containers and encodings that utilize of XML, JSON, STANAG and/or JOSE standards. The chapter recommends new media type definitions required for content negotiation in "DCS aware" APIs.

Chapter 9 provides a summary of the main findings and explains the results in the implementation for the architecture used in Testbed-16. This section also lists the challenges which were tackled during the design and implementation process.

Chapter 10 considers interesting topics to be researched in future work.

Appendix A provides code snippets that illustrate the XML and JSON encodings as well as container structures based on STANAG and JOSE.

Appendix B explains the engineering aspects of the DCS components D120 (DCS Server) and D145 (Key Management Server).

Appendix C introduces the engineering aspects of the DCS component D146 (Key Management Server).

Appendix D presents Access Control Policies for DCS Server and Mobile Clients.

Appendix E presents DCS Roles Concept and Approach for Mobile Clients.

This chapter describes the DCS architecture following the general concept of multiple views. This approach identifies architectural elements while illustrating and validating the architecture design. The contents of the chapter have views of logical, component, process and deployment. However, the focus of the chapter is on the logical components and their interactions. Appendices dedicated to the components provide an overview related to the practical deployment of logical system components (physical or deployment view).