Publication Date: 2021-02-26
Approval Date: 2021-02-25
Submission Date: 2021-11-18
Reference number of this document: OGC 20-021r2
Reference URL for this document: http://www.opengis.net/doc/PER/t16-D011
Category: OGC Public Engineering Report
Editor: Aleksandar Balaban
Title: OGC Testbed-16: Data Centric Security Engineering Report
COPYRIGHT
Copyright © 2021 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.ogc.org/
WARNING
This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Public Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.
LICENSE AGREEMENT
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.
- 1. Subject
- 2. Executive Summary
- 3. References
- 4. Terms and definitions
- 5. Overview
- 6. Data Centric Security (DCS)
- 7. Requirements, Scenarios and Architecture
- 8. Data Encodings, DCS Containers and Media Types
- 9. Results
- 10. Future Work
- 11. Technology Integration Experiments (TIEs)
- Appendix A: Engineering Aspects for D120 and D145
- Appendix B: Engineering Aspects for D146
- Appendix C: Access Control Policies for DCS Server and Mobile Clients
- Appendix D: Data Centric Security Roles
- Appendix E: Revision History
- Appendix F: Bibliography
1. Subject
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.
2. Executive Summary
OGC members can derive business value from this ER in the following areas:
-
Similarities between the DCS approach in the geospatial domain and the well-known commercial/enterprise Digital Rights Management (DRM) architecture for provision of protected multimedia contents. Also, the commercial geospatial content could be provided using this approach.
-
Interoperability through the support for different encoding standards such as Extensible Markup Language (XML) and JSON, as well as the utilization of different container structures, such as STANAG 4774/8 and JOSE to support a variety of encoding standards and container formats.
-
How to use the OGC API - Features Standard to enable client requests the DCS protected content encoded in a preferred way and how the OGC API - Features can be extended with content negotiation via additional media types.
-
Common security context shared by all components. Bearer access tokens are issued by a common Authorization Server as defined in RFC 6750. The use of OAuth2 and OpenID Connect interfaces ensures interoperability.
-
Data-centric Security (DCS) architecture which contains a dedicated Key management server or KMS.
-
KMS API based on the OASIS Key Management Interoperability Protocol Specification 2.x provides interoperable solution and gives the strong protection for keys afforded by KMIP-compliant Servers.
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:
-
Federated DCS architecture, which enable the collaboration (establishing of a required level of trust) among distinctive security domains.
-
Additional media types for encoding and structuring of DCS protected binary data such as binary maps, tiles and coverages.
-
Creation of new and update of already existing entities for DCS protected data sets.
-
Standardized packaging distribution format(s) for all required artefacts such as policies, keys and protected data payload.
-
Data-centric security for JP2 and GMLJP2 payloads.
-
Standardize KMS
2.1. Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Contacts
Name | Organization | Role |
---|---|---|
Aleksandar Balaban |
m-click.aero |
Editor |
Andreas Matheus |
Secure Dimensions |
Contributor |
Michael Leedahl |
Maxar |
Contributor |
George Elphick |
Helyx Secure Information Systems |
Contributor |
Marcus Alzona |
keys |
Contributor |
2.2. Foreword
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.
3. References
The following normative documents are referenced in this document.
-
GeoDRM RM Geospatial DRM Reference Model (GeoDRM RM)
-
NATO: "ADatP-4774" Confidentiality Metadata Label Syntax, edition A version 1, NSO, 2017.
-
NATO: "ADatP-4778" Metadata Binding Mechanism, edition A version 1, NSO, 2018.
-
IETF: The OAuth 2.0 Authorization Framework: Bearer Token Usage
-
OGC: GeoXACML3 - GML 3.2.1 Encoding Extension, OGC Discussion Paper
-
OGC 16-040r1, Testbed-12: Aviation Security Engineering Report
-
OGC 12-139, OWS-9: SSI Security Rules Service Engineering Report
-
OASIS Key Management Interoperability Protocol Specification Version 2.1
-
PyKMIP: A Python implementation of the Key Management Interoperability Protocol (KMIP)
4. Terms and definitions
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.
AS |
OAuth2 Authorization Server — a component that dispatches, validates manages bearer access tokens. |
CRUD |
In computer programming, create, read (aka retrieve), update, and delete are the four basic functions of persistent storage. |
DCAP |
Data centric audit and protection, term used by Gartner to describe an approach to information security that combines data security and audit with discovery, classification, policy controls, user and role based access, and real-time data and user activity monitoring to help automate data security and regulatory compliance. |
GeoPDP |
Geospatial Policy Decision Point — a component of a policy based system that uses a request, attributes about a request (including geospatial attributes) and a policy document to make an access decision to allow access to a resource. The GeoPDP implements the OGC GeoXACML implementation specification. |
GeoPEP |
Geospatial Policy Enforcement Point — a component of a geospatial aware policy based system that works with a GeoPDP to enforce access decision and perform obligations requested by the GeoPDP. |
OGC API |
A new OGC API Features Part 1 Core standard for a feature service application programming interface that provides access to feature collections and the items in them. This standard was formally known as WFS3 for Web Feature Service version 3. |
LDProxy |
LDProxy — An Open Source product by Interactive Instruments which provides most of the REST implementation specified in the OGC API - Features Standard. |
PDP |
Policy Decision Point — a component of a policy based system that uses a request, attributes about a request (including geospatial attributes) and a policy document to make an access decision to allow access to a resource. The PDP implements the OASIS XACML3 standard. |
STANAG |
In NATO, Standardization Agreement, defines processes, procedures, terms, and conditions for common military or technical procedures or equipment between the member countries of the alliance. |
4.1. Abbreviated terms
ADR |
Authorization Decision Request |
DCS |
Data Centric Security |
DRM |
Digital Rights Management |
GeoPDP |
Geospatial Policy Decision Point |
GeoPEP |
Geospatial Policy Enforcement Point |
GeoXACML |
Geospatial eXtensible Access Control Markup Language |
JOSE |
Javascript Object Signing and Encryption |
JWT |
JSON Web Token |
KMS |
Key Management Server |
OAPIF |
OGC API - Features |
OGC |
Open Geospatial Consortium |
PDP |
Policy Decision Point |
PEP |
Policy Enforcement Point |
SAML |
Security Assertion Markup Language |
STANAG |
Standardization Agreement |
WFS3 |
Web Feature Service version 3 (Also known as OGC API Features) |
XACML |
eXtensible Access Control Markup Language |
XML |
eXtensible Markup Language |
XSLT |
eXtensible Stylesheet Language Template |
5. Overview
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.
6. Data Centric Security (DCS)
6.1. Introduction
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.
6.2. Key Concepts
A data-centric security model includes:
-
Discover: The ability to inspect data storage areas to detect sensitive information.
-
Manage: The ability to define access policies that will determine if certain data is accessible, editable, or blocked from specific users, or locations.
-
Protect: The ability to defend against data loss or unauthorized use of data and prevent sensitive data from being sent to unauthorized users or locations.
-
Track: The constant monitoring of data usage to identify meaningful deviations from normal behavior that would point to possible malicious intent.
According to established theoretical models DCS relies on the implementation of the following:
-
Information (data) that is self-describing and defending, which means metadata that describes the information and the security of data does not depend on applications and infrastructure.
-
Information that remains protected as it moves in and out of applications and storage systems, and changing business context.
-
Policies and controls that account for business context (relevant use case scenarios)
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:
-
Unclassified
-
Restricted
-
Confidential
-
Secret
-
Top Secret
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".
<originatorConfidentialityLabel xmlns="urn:nato:stanag:4774:confidentialitymetadatalabel:1:0">
<ConfidentialityInformation>
<PolicyIdentifier>DCS_TB-16</PolicyIdentifier>
<Classification>SECRET</Classification>
<GenericValue>OGC</GenericValue>
</ConfidentialityInformation>
</originatorConfidentialityLabel>
7. Requirements, Scenarios and Architecture
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).
7.1. Requirements
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
R01 |
DCS architecture will contain a key management service or KMS component, which shall be able to create, register, issue and invalidate keys used to protect the content in the context of DCS. |
R02 |
KMS shall utilize standard or dedicated API to allow the communication with other components. |
R03 |
DCS architecture shall provide the mechanism for content negotiation. Said differently, a client informs the content provider (DCS server) about the preferable encoding of the content and container format. |
R04 |
The OGC API - Features shall provide data protection independent of the transport. Identities, tokens, keys, access rights, policies have to be supported by the API. |
R05 |
DCS architecture shall keep support for XML/STANAG 4774/8 encoding for DCS payload containers. |
R06 |
DCS architecture shall support JSON encoding for DCS payload containers. |
R07 |
DCS architecture shall use well-established standards (JOSE) when implementing the JSON encoding for DCS containers. |
R08 |
DCS architecture shall support encryption for meta-data in DCS containers. |
7.2. Scenarios (Use Cases)
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.