I. Abstract
This OGC Testbed-17 Engineering Report (ER) documents the enhancement of applying Data Centric Security (DCS) to OGC API Features, OGC API Maps (draft), and OGC API Tiles (draft).
As organizations move to the cloud, it is important to incorporate DCS into the design of the new cloud infrastructure, enabling the use of cloud computing, even for sensitive geospatial data sets. The ER documents the applicability of Zero Trust through a Data Centric security approach (DCS) when applied to vector and binary geospatial data sets (Maps, Tiles, GeoPackage containers) and OGC APIs.
The defined architecture extends the typical Zero Trust Domain component by introducing a Key Management System (KMS) to support key registration and the management of access conditions for key retrieval. The prototype implementations (DCS Client, DCS Server and KMS) demonstrate how to request encrypted geospatial data as JSON for encrypted vector data, HTTP Multipart for encrypted map data or GeoPackage with encrypted content; how to obtain decryption key(s) and how to decrypt and display the protected data in a mobile application on Android.
II. Executive Summary
Data Centric Security (DCS) is an approach to apply security directly to data, independent from security features provided by a network, servers or applications. For Data Centric Security in the geospatial domain, proof-of-concept implementations were developed through work in OGC Testbed-15 and Testbed-16. Initially Extensible Markup Language (XML) based standards to label and protect geospatial feature data in Testbed-15 according to the NATO STANAG 4774 and 4778 specifications, the work expanded into JavaScript Object Notation (JSON) based structures during Testbed-16.
For Testbed-17, the primary goal of the DCS task was to apply Data Centric Security in the context of OGC API Standards that enable the delivery of binary data representations such as images and GeoPackage.
The motivation for applying Data Centric Security is the ability to protect sensitive data independently from controlling the access to systems storing and transferring such data. An example of such systems is increasingly popular cloud-based data storage or content delivery platforms. A fundamental requirement is that the data sets are 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. When looking at drafting OGC Standards such as an OGC API in a Data Centric Security scenario, standards need to include ways to classify the security requirements around data access. Data Centric Security protected data could be stored locally at the client location in order to be used within the validity period of time.
OGC members can derive business value from applying Data Centric Security in the following areas:
-
Similarities between the Data Centric Security approach in the geospatial domain and the commercial/enterprise Digital Rights Management (DRM) architecture improves marketing perspectives: Distributing protected geospatial binary content (satellite imagery, sensitive content structured as a GeoPackge container) is similar to DRM.
-
Flexible control over the decryption via a fit-for-purpose Key Management System.
-
Interoperability through the support for different encoding standards such as XML and JSON. Work in Testbed-17 demonstrated the interoperability for DCS protected binary geospatial data sets and a way to protect and distribute packaged content.
-
Leverage a common Zero Trust Domain architecture whereby a common security context is shared by all components based on Bearer Access Tokens as defined in The OAuth 2.0 Authorization Framework: Bearer Token Usage.
-
Use GeoPackage with (individually) encrypted data for OGC API — Features or — Tiles that offer flexible decryption of content as necessary. This is an advantage compared to the standard approach of encrypting entire GeoPackage files, as these need to be decrypted as a whole before content can be extracted. The introduced approach allows for example mobile applications to just decrypt those tiles or features that are to be rendered on the display. This saves memory, increases performance and thereby extends battery lifetime.
The Testbed-17 DCS work envelope is defined by the results from Testbed-16 and the ambition to establish DCS for OGC API responses containing binary data. In particular, the following questions were considered:
-
How can an implementation of the draft OGC API — Maps specification be used to return an encrypted image of a map request?
-
How can an implementation of the OGC API — Features standard be used to return a GeoPackage container that contains encrypted features?
-
How can an implementation of the draft OGC API — Tiles specification be used to return a GeoPackage container that contains encrypted tiles?
-
Which metadata fields in the response allow a client application to successfully decrypt the “blob” of data?
-
How can one be assured that the decryption of the encrypted responses can only be carried out with trusted applications and legitimate users?
-
What are the implications of processing encrypted data regarding storage, processing times for encryption and decryption, as well as CPU burden?
The Testbed-17 findings demonstrate the ability to support Data Centric Security applied to binary geospatial data sets. A mobile client application running on the Android operating system was implemented to request and decrypt protected binary content, such as encrypted images (OGC API — Maps (draft)), encrypted features (OGC API — Features) as well as GeoPackages with encrypted content based on OGC API — Features and OGC API — Tiles (draft).
In support of the experimentation in this Testbed, several Technology Integration Experiments (TIEs)/scenarios were defined:
-
The first scenario depicted the exchange of DCS-protected content from an OGC API Maps implementation.
-
The second scenario depicted the exchange of DCS-protected content from an OGC API Features implementation.
-
The third scenario depicted the exchange of DCS-protected GeoPackages containing encrypted features or map tiles requested via implementations of OGC API — Features or OGC API — Tiles.
This ER introduces GeoPackage encryption extensions for storing Features or Tiles in Annex A.
Future OGC Innovation Program activities should extend and implement access control based on spatio-temporal policies to complement the Testbed-17 Data Centric Security architecture towards a Zero Trust Domain architecture. In particular, further activities could demonstrate how to implement the Data Centric Security architecture (including access control) in a Federated Security environment as outlined in OGC Testbed-16: Federated Security. Another future activity should focus on the standardization of a Key Management System API meeting the specific requirements for key management with Data Centric Security enabled geospatial data.
III. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, Data-Centric Security
IV. Preface
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.
V. Security Considerations
When applying Data Centric Security, a false assumption might be drawn that encryption of data is the compulsory solution to everything. This is not true. Why? It is certainly possible to tamper encrypted data so that it still decrypts, but would produce fraudulent information in the “clear” (after being decrypted). Encryption provides confidentiality, as the encrypted data can only be transformed into the “clear” by applications or users that are in possession of the decryption key (and support for the cipher algorithm in use).
To completely trust encrypted data, assurance about integrity and most likely authenticity must be implemented. Even though the implementation of integrity also relies on encryption, it focuses on encrypting the hash value of the data (either before or after it was encrypted) and not the data itself. Whereas encryption is usually based on a shared secret (as symmetric key), digital signatures require the use of asymmetric keys (a public key shared with all relevant entities and a private key under sole possession of the owning user). Extending integrity to authenticity is quite simple, as it only requires that a certificate is created (by a trusted Certificate Authority) that bundles the public key with the identity information of the entity that owns (and is in single possession of) the associated private key.
Testbeds 15, 16 and 17 have successfully demonstrated how confidentiality can be applied to geospatial data, returned via OGC APIs. The focus was to encrypt responses:
-
OGC API Maps for DCS returns a HTTP Multipart response where the second part represents the encrypted binary data of the map image
-
OGC API Features for DCS returns a JSON container containing a collection of encrypted features encoded in GeoJSON or a GeoPackage where each feature entry is encrypted
-
OGC API Tiles for DCS returns a GeoPackage where each tile data is encrypted
The Testbed 17 result GeoPackage Encryption Extension provides — as the name suggests — an approach to ensure confidentiality of the data stored in a GeoPackage. There is no guarantee about the integrity of the GeoPakage or even its authenticity. To ensure integrity of a GeoPackage, and thereby making it possible to detect tampering, it would be required to calculate the hash value for the entire GeoPackage and then create a digital signature. This digital signature would then have to be stored with some trusted entity, like a Content Delivery Network (CDN), that allows to retrieve the digital signature of a hash value. A similar process is in place for the distribution of binary software packages: JavaScript download with integrity check or Linux package distribution leverages SHA256 or SHA384 hash value verification.
VI. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- m-click.aero GmbH
- Secure Dimensions GmbH
VII. Submitters
All questions regarding this document should be directed to the editor or the contributors:
Name | Organization | Role |
---|---|---|
Aleksandar Balaban | m-click.aero GmbH | Editor |
Andreas Matheus | Secure Dimensions GmbH | Editor |
Adam Parsons | Compusult Ltd. | Contributor |
Testbed-17: Data Centric Security ER
1. Scope
This OGC Engineering Report (ER) is deliverable D007 of the OGC Testbed-17 activity (Data Centric Security Across OGC APIs) performed as an OGC Innovation Program activity.
This document expands on the results in the area of geospatial Data Centric Security from OGC Testbed-16 by evaluating options to request binary geospatial data formats via implementations of the draft OGC API — Maps, and OGC API — Tiles, and the approved OGC API — Features standard. In particular, this ER discusses and outlines the approaches for extending the OGC GeoPackage Encoding Standard to support encrypted data (features or map tiles) plus adequate metadata for enabling client applications to perform the integrity checking, decryption and visualization. Regarding the use of image data formats, this ER also describes how the draft OGC API Maps could be extended to return encrypted map images as a HTTP Multipart response.
Another addition in the anticipated usage scenarios (and therefore in TIEs) is that encrypted content delivered as a GeoPackage container remains in the client’s (local) storage and can be decrypted and displayed multiple times. It is also possible to share locally stored GeoPackage content with other users and applications by adopting access conditions to the (decryption) key via the Key Management System.
When it comes to identifying an architecture to solve a particular problem or challenge, it is wise to not start from scratch if working solutions exist. In that sense, the Testbed-17 architecture differs only slightly from the Testbed-16 architecture.
Figure 1 — Testbed-17 Architecture
The Testbed-17 DCS architecture consists of the following components:
Authorization Server (AS)
This component remains unchanged from Testbed-16: It acts as an OAuth2 / OpenID Connect compliant Authorization Server. The DCS Client application requests access tokens from this component after the user has logged in. The DCS Server and Key Management Server use the Authorization Server’s Token Introspection endpoint to validate access token.
Identity Management (IdM)
The Identity Management component supports social login from Facebook, Google and the OGC, as well as approximately 2800 universities. When logging in via the OGC portal IdP, a user’s active OGC projects become available as OpenID Connect claim ogc-is-member-of which can be used to undertake access control. This component is tightly integrated with the AS component.
Key Management Server (KMS)
This component ensures that (de/en)cryption keys can be created, registered and obtained from applications and services by presenting an access token. The KMS also supports the modification of access conditions of registered keys by owning users.
DCS Server
This component is implemented as a plugin to GeoServer v2.20 that supports to request encrypted responses for the OGC’s Maps, Features and Tiles APIs. In order to execute the plugin, the standard OGC APIs must be extended with additional request parameters. On behalf of a user, for each request, the DCS Server generates and registers (de/en)cryption keys with the KMS.
NOTE 1 The DCS Server’s implementation changed from a generic OGC API Proxy to an extension plugin (module) to GeoServer. This tight integration is necessary to accommodate a high performance processing when creating GeoPackage containers with encrypted content.
DCS Client
This component was implemented as an Android mobile application that supports the DCS protocol offered by the DCS Server to request, decrypt and visualize encrypted responses of various encoding, as documented in the TIE section (See Clause 6).
NOTE 2 The DCS Client changed from a QGIS plugin to an Android mobile application.
2. Terms, definitions and abbreviated terms
This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.
This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.
For the purposes of this document, the following additional terms and definitions apply.
2.1. Terms and definitions
2.1.1. Access token
A token that can be provided as part of a service request that grants access to the service being invoked on. This is part of the OpenID Connect and OAuth 2.0 specification.
2.1.2. Assertion
Information about a user. This usually pertains to a JWT authentication response that provided identity metadata about an authenticated user.
2.1.3. Authentication
The process of identifying and validating a user.
2.1.4. Authorization
The process of granting access to a user.
2.1.5. Credentials
Credentials are pieces of data used to verify the identity of a user.
2.1.6. Client
Clients are applications that want to request identity information or an access token so that they can securely invoke DCS secured services.
2.1.7. 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.
2.1.8. Identity token
A token that provides identity information about the user. Part of the OpenID Connect specification.
2.1.9. Identity provider
An identity provider (IdP) is a service that can authenticate a user.
2.1.10. Federated identity
Federated identity defines linking and using the identities that a user has across several security domains/realms and their identity providers.
2.1.11. OGC API
The OGC API family of standards is a suite of open standards for Web APIs that offer modular building blocks that make it easy for anyone to publish or consume geospatial data on the web.
2.1.12. Realms
A realm contains a set of users and their attributes (credentials, roles). A user belongs to a realm. Realms are isolated from one another and only manage and authenticate the users that they control.
2.1.13. Roles
Roles identify a type or category of user. Admin, user, manager, and employee are all typical roles that may exist in an organization. Applications often assign access and permissions to specific roles rather than individual users.
2.1.14. Users
Users are entities that are able to log into a system. They can have attributes and have specific roles assigned to them.
2.2. Abbreviated terms
AS
-
Authorization Server
CDN
-
Content Delivery Network
DCAP
-
Data centric audit and protection
DCS
-
Data Centric Security
DEK
-
Data Encryption Key
DRM
-
Digital Rights Management
GeoXACML
-
Geospatial eXtensible Access Control Markup Language
IdM
-
Identity Management
JOSE
-
Javascript Object Signing and Encryption
JSON
-
JavaScript Object Notation
JWT
-
JSON Web Token
KEK
-
Key Encryption Key
KID
-
Key ID
KMS
-
Key Management Server
LBAC
-
Label-based access control
OGC
-
Open Geospatial Consortium
SAML
-
Security Assertion Markup Language
STANAG
-
NATO Standardization Agreement
TIE
-
Technology Integration Experiment
XACML
-
eXtensible Access Control Markup Language
XML
-
Extensible Markup Language
ZTA
-
Zero Trust (Architecture)
3. Introduction
The primary goal of the Testbed-17 Data Centric Security (DCS) task was to apply DCS in the context of OGC API Standards that deliver binary data representations such as images and GeoPackage. The motivation for applying Data Centric Security was the ability to protect sensitive data independently from controlling the access to systems storing and transferring such data.
The following questions were considered in the Testbed-17 Data Centric Security (DCS) task:
-
How can an implementation of the draft OGC API — Maps specification be used to return an encrypted image of a map request?
-
How can an implementation of the OGC API — Features standard be used to return a GeoPackage container that contains encrypted features?
-
How can an implementation of the draft OGC API — Tiles specification be used to return a GeoPackage container that contains encrypted tiles?
-
Which metadata fields in the response allow a client application to successfully decrypt the “blob” of data?
-
How can one be assured that the decryption of the encrypted responses can only be carried out with trusted applications and legitimate users?
-
What are the implications of processing encrypted data regarding storage, processing times for encryption and decryption, as well as CPU burden?
4. Results
This chapter summarizes the key findings regarding DCS data formats and implications to standardization when applying DCS to OGC APIs and the GeoPackage encoding. It further lists issues and security implications when using the GeoPackage encoding.
4.1. Binary data formats for DCS
Depending on the OGC API Standard, different packaging and response encoding make sense. In particular the OGC API Features does only support one binary response encoding that was tested within this Testbed: GeoPackage. The capabilities of the OGC API Features limit request features for only one collection_id. Therefore, a GeoPackage with encrypted content only contains one DCS related table. However, the GeoPackage Encryption Extension for Features defined in the Annex A does support storing features of different types into different tables. This can be illustrated when requesting a DCS GeoPackage via the WFS 2.0 interface.
NOTE The use of WFS 2.0 for requesting DCS GeoPackage was not an official part of the work and therefore not included in the TIE.
For the OGC API Features standard, it is possible to apply the DCS data format as an extension to XML and JSON. Both approaches were already implemented and documented during Testbed-16. To summarize, the STANAG 4778 XML encoding is supported where the content is GML encoded and JSON structured responses include JWE representations of GeoJSON encoded Features. Please see OGC Testbed-16: Data Centric Security Engineering Report for more details.
For the OGC API Maps and Tiles draft standards that support the return of binary image data (media type image/*), the data could be encrypted by the DCS Server before returning the response to the client. In this Testbed, the equivalent to DRM online streaming, where the application and server negotiate an encryption key to be used for streaming encrypted content, was not implemented. Instead, the more generic approach was implemented, where the encryption key is managed by a KMS.
In this case, the client must obviously receive information about the DEK, aka key metadata with the encrypted binary data. For conveying the encrypted image data and the DEK metadata for the OGC API Maps, the HTTP Multipart response format is used. More details are illustrated in Figure 4.
4.2. DCS GeoPackage Extension
A GeoPackage is the SQLite container and the OGC GeoPackage Encoding Standard governs the rules and requirements of content stored in a GeoPackage container. The GeoPackage standard defines the schema for a GeoPackage, including table definitions, integrity assertions, format limitations, and content constraints. Defined by the Open Geospatial Consortium (OGC)[2] membership with the backing of the US military[3] and published in 2014, GeoPackage has seen wide support from various government, commercial, and open source organizations.
The GeoPackage standard describes a set of conventions for storing the following within a SQLite database:
-
Vector features
-
Tile matrix sets of imagery and raster maps at various scales
-
Attributes (non-spatial data)
-
Extensions
This Testbed-17 Engineering Report defines two GeoPackage extensions to store encrypted data:
-
GeoPackage Encryption Extension to store Features
-
GeoPackage Encryption Extension to store Tiles
See Annex A for more details.
4.2.1. General Containerized Format
Inspired by previous work using XML structures defined in STANAG 4778 and 4774, previous Testbeds already defined a general containerized format based on JSON encoding: OGC Testbed-16: Data Centric Security Engineering Report.
Testbed-17 continued this response format for the OGC API Features via the media type application/dcs+geo.
4.3. Implications for OGC API Standardization Development and Implementation
For applying the concepts of Data Centric Security as a building block to OGC (Features, Maps, Tiles, etc.) APIs being able to easily extend the protocol with additional parameters is important. Of related importance is that implementations of OGC APIs — that have potential wider use beyond just the “traditional” GIS Community — support flexible processing of additional request parameters and support returning “custom” response formats.
When applying DCS relevant parameters to the OGC APIs leveraging a POST request (www-url-form-encoded) as a secure alternative for the HTTP GET must be possible. This is in particular important if Bearer Access Tokens cannot be added to the HTTP Authorization Header or, when a user requests encrypted content but does not want to disclose the “layers” or “feature types” within the HTTP GET request!
IMPORTANT
OGC APIs and their implementations must support the declaration and processing of extensions that define new building block with specific request parameters.
IMPORTANT
OGC APIs and their implementations must support a security building block classed “HTTP Bearer Token” (RFC 6750).
IMPORTANT
OGC APIs and their implementations must support HTTP POST as a secured alternative to HTTP GET. This is in particular important when sending sensitive parameters to the server.
4.4. Discovered Issues with GeoPackage as response format
When applying encryption to data, the processing burden must obviously be considered. When extending APIs (such as the OGC APIs) that are designed to quickly return short to medium size responses (up to some MBs), the potentially large size, as well as long time required to DCS-protect returning GeoPackage container can turn out to become a kind of Denial-Of-Service attack.
Most OGC API Standards define synchronous RESTful web services, which means that the service returns a HTTP 200 OK success status and the response on the same socket pair as the one used to receive the request. This interaction pattern is acceptable, if the requested response format is streaming-ready. A streaming-ready response format is ZIP. The server can open a Zipped output stream and start immediately to push data down to the client. In the case of GeoPackage, this is not possible as a GeoPackage container is a binary file format that must first be completely created (on the server’s storage) before the stream towards the client can start. For large GeoPackages, or for those where the creation takes a long time due to encryption, different issues may arise:
-
The user client might disconnect from the socket after the TCP standard timeout. The DCS client was not aware of the requirement to set an extra-long (endless) timeout before making the request. Unfortunately, the service — meanwhile creating the GeoPackage — remains unaware of client disconnection, finishes package generation and eventually starts an attempt to deliver the data to the client. Therefore, the service might generate a large GeoPackage and waste CPU and memory by processing a request for which there is no longer a receiver.
-
The creation of the (temporary) GeoPackage on the Server produces no space left on device error. In this case, the user would receive an error but most likely retry. This is a dangerous situation, as the server’s storage might become spammed with long running GeoPackage processing tasks, which were started on behalf of perhaps disconnected clients.
-
Inattentive or malicious users might produce a sequence of requests by click — cancel — repeat. The issue arises that all requests but the last are lost, as the cancel most likely disconnected the TCP socket.
These situations can quickly turn into a denial-of-service (DoS) attack, if resource quotas that limit resource consumption (per service request) aren’t put in place.
In this testbed, the participants created GeoPackage sizes of 12GB for the default GeoServer data set (Tiger Roads) when requesting TileMatrixSet 0-21. The processing time on a medium size server took approximately 6 hours to create the container. Without a resource quota, the server resources are quickly not available.
A possible solution for problems mentioned above would be to utilize an asynchronous service design allowing clients to submit a GeoPackage processing request, disconnect and wait for the service to generate the required package (a long time running backend task). In order to prevent multiple service calls caused by malicious or unintentional repeated data requests, clients should further be limited on how many of such tasks they are allowed to submit at a time. Finally, The OGC API — Processes standard may fit right to implement such interaction in an OGC compliant way. OGC API — Processes defines an API that supports both synchronous and asynchronous execution of computing processes (and the retrieval of metadata describing their purpose and functionality).
5. Implementation Aspects
The Testbed-17 DCS architecture extends the Testbed 15 and 16 architectures by supporting encryption of binary responses for the OGC API Features, Maps (draft), and Tiles (draft) standards. This feature is implemented in the DCS Server. The DCS client is a mobile application running on Android.
NOTE The aim of this section is to provide a detailed Overview about all aspects of design and component development.
5.1. Architecture Overview
The overall architecture supporting the DCS goal is very similar to the one from Testbed-16 (see OGC Testbed-16: Data Centric Security Engineering Report for more details). The following figure illustrates the overall architecture.
Figure 2 — Testbed-17 Architecture
The Testbed-17 DCS architecture is inspired by the Zero Trust definition as outlined in the OGC Testbed-16: Federated Security Engineering Report: Each request to a DCS enriched OGC API and the KMS requires authentication. This is achieved through the DCS Client that requires an acting user to login first. This results in a Bearer Access Token that the DCS Client requests from the AS. The Bearer Access Token must be used for all requests to the DCS Server and the Key Management Server. Based on the user’s identity that is linked to the Access Token, the DCS Server and KMS apply access control based on the user’s access rights.
Before making a request to the DCS Server, the user has to provide a PIN or secret to the DCS Client. This PIN is added to the request and used as a proof of ownership to the Data Encryption Key (DEK), generated by the DCS Server. The PIN is required to manage the access conditions for the DEK with the KMS at a later stage. Upon a successful request, the DCS Server returns the DCS specific response. In all cases, the encrypted data in the response is based on a cipher key that was created by the DCS Server and registered with the KMS. Therefore, to decrypt the response, the client first parses the response to find the DEK metadata; in particular the kid (key identifier) and the kurl the URL to fetch the key from the KMS. Depending on the actual response format, this information is at different places but is always in a standardized format, leveraging the JSON Web Key specification (RFC 7517). Before undertaking the actual decryption of the response, the client interacts with the KMS and fetches the DEK. In case the KMS returns “forbidden”, the acting user should verify the access conditions for the key, in particular the expiration time. Amendment to the conditions and in particular to the expiration time can be done via the KMS admin pages. To change the access conditions for a DEK, the user has to provide the PIN.
Figure 3 — Testbed-17 DCS Architecture Interactions Overview
As illustrated in Figure 3, the interactions can be categorized as follows:
Category (A)
Interactions from the client to the server are based on an extension to the parameters defined for the OGC APIs:
-
access_token parameter (mandatory) contains the value of the Bearer Access Token
-
key_challenge parameter (mandatory) that contains the (hashed) PIN
-
key_challenge_method parameter (mandatory) is either plain or S256. When using S256, the value of the key_challenge must be hashed according to Proof Key for Code Exchange by OAuth Public Clients, Sect. 4.2.
Responses from the server to the client contain the encrypted data.
Category (B)
The server interacts with the KMS to register the DEK that was generated to encrypt the content for the current request.
The response from the KMS contains the DEK identifier (kid).
Category (C)
Interactions between the client and the KMS to fetch a DEK for decrypting the actual response from the server or a GeoPackage that was loaded from (local) storage. The request parameters are
-
access_token (mandatory) as defined above
-
kid (mandatory) as part of the path (/dek/{kid})
-
kek_kid (optional) contains the key identifier for a registered public key that is to be used by the KMS to return the DEK encrypted
The response from the KMS to the client is the JWK encoding of the DEK, including the key’s secret. When the request contains the kek_kid parameter, the response is a JWE where the payload is the JWK encoding of the key. (The referenced public key is used for key wrapping)
Category (D)
In case that the client wants to request encrypted key material defined by interactions of category (C), the client can use the KMS KEK (Key Encryption Key) API to register a public key in JWK format. The key identifier received in the response can be used as illustrated above in category (C).
5.2. DCS Server
The DCS Server implementation by Secure Dimensions is realized as a GeoServer Plugin, available from Github: GeoServer DCS Plugin. For the OGC Testbed-17 initiative, the implementation demonstrates the ability to apply Data Centric Security to geospatial data, requested via implementations of the OGC’s Features, Tiles (draft) and Maps (draft) APIs. In order to support the DCS feature, the OGC API requests are extended with additional query parameters:
-
access_token (mandatory) as defined above
-
kid (mandatory) as part of the path (/dek/{kid})
-
kek_kid (optional) contains the key identifier for a registered public key that is to be used by the KMS to return the DEK encrypted
The request parameter f determines the response format based on DCS specific media types, valid in the context of this Testbed. The DCS Server implementation supports different response formats specific to an OGC API. The response format for OGC API Maps is a HTTP Multipart response where the first part contains the key metadata in JSON encoding and the encrypted image is an octet-stream provided as part two. For the OGC API — Features standard, two different response formats are supported: (i) encrypted features in JSON container and (ii) GeoPackage container holding encrypted features. For the OGC API — Tiles draft specification, only GeoPackages holding encrypted tiles are supported.
Table 1 — OGC Testbed-17 DCS Media Types
OGC-API | DCS Media Type | Description |
---|---|---|
Features | application/dcs+geo | DCS container structure encrypted features, metadata as JSON |
Features | application/dcs+geo;profile=metaSign | DCS container structure encrypted features, metadata as JWS |
Features | application/dcs+geo;profile=metaEncrypt | DCS container structure encrypted features, metadata as JWE |
Features | application/gpkg+dcs | GeoPackage with encrypted features |
Tiles | application/gpkg+dcs | GeoPackage with encrypted tiled coverages |
Maps | application/dcs+{png,jpeg,…} | Multipart response with encrypted map tiles |
The actual GeoPackage extensions for encrypted Tiles and Features are described in section “GeoPackage Data Centric Security Extensions” (Annex A).
5.2.1. OGC API Maps Response Format
The OGC API Maps implementation returns an image in the format requested. Typical formats are PNG or JPEG. The DCS response format can be requested via the f parameter using the DCS specific media type `application/dcs+{<image format>}.
The structure of the response as a HTTP Multipart is illustrated in the following figure.
Figure 4 — DCS Testbed-17 OGC API Maps Interactions Overview
As illustrated in Figure 4, the response uses content type multipart/encrypted; protocol=application/json. This is a standard way to ‘alert’ the client about the encodings of the different parts. The response header further contains the boundary identifier of the multi part message (f92d9092-6c6b-48e0-a4b3-16fc71be9d63 in the example above).
The following is an example first part:
{
"metadata": {
"originator_confidentiality_label": {
"confidentiality_information": {
"policy_identifier": "TB17",
"classification": "Confidential"
}
},
"data_producer": {
"origin": "Not NGA",
"date": "2021-10-01T14:03:08.409Z"
},
"data_description": {
"type": "Feature",
"properties": {
"name": "tiger:tiger_roads",
"content_type": "application/geo+json"
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
-74.02722,
40.684221
],
[
-73.907005,
40.684221
],
[
-73.907005,
40.878178
],
[
-74.02722,
40.878178
],
[
-74.02722,
40.684221
]
]
]
}
}
},
"dek_info": "eyJqa3UiOiJodHRwczpcL1wvb2djLnNlY3VyZS1kaW1lbnNpb25zLmNvbVwvZGNzXC8ud2VsbC1rbm93blwvandrcy5qc29uIiwia2lkIjoiRHIuIE5vIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiI5NWQzODI3ZC1lZmVmLTMwNTItYTJkZi00NmQxYzdjZTc3YTUiLCJhdWQiOiIwMTliNzE3My1hOWVkLTdkOWEtNzBkMy05NTAyYWQ3YzA1NzUiLCJrdXJsIjoiaHR0cHM6XC9cL29nYy5zZWN1cmUtZGltZW5zaW9ucy5jb21cL2ttc1wva2V5c1wvMTU1MTdlOTUtYzc2NC00NjAyLTllMDktN2FhYWQxMDRkNDgwIiwia2lkIjoiMTU1MTdlOTUtYzc2NC00NjAyLTllMDktN2FhYWQxMDRkNDgwIiwiaXNzIjoiaHR0cHM6XC9cL29nYy5zZWN1cmUtZGltZW5zaW9ucy5jb20iLCJleHAiOjE2MzMwOTgsImFsZyI6IkExMjhHQ00iLCJpYXQiOjE2MzMwOTY5ODYzNzJ9.T5BeNmsSLPSfZniVziJe_7tobLBaA7wxP1wqKGliHq37JbLFMzlqLXmAnSDtSqNjQUtNycRXgkGKADbKUkBsht6o7GrI24Ox3h41F_HGTVCnxIwr1AlQtA0xEK9QqP-CYjOiRITuHlBDZis6AjF-NCxLdXuplZ5OY9R_Y3uaduoV4Klczy4xBXOFI2iA8qA8O1wCUUcYpaNm8-EalS5Jx0ve_xOT_wVquC6Q2Gyz9LF0gjGQ01mhEmw6ZAOWLtiW6xphK34gakp1_oJXeqPWFPo2mDtlCi3DXe2yLhTrY_uA0_7QAAGPOK9gskHotTZ9FJ-UffKPbs-TkPVEHTapQQ"
}
Part 1 of the Multipart response
In clear JSON encoding, the client can determine information about the confidentiality labelling, the data producer and the actual data structure. In particular, the boundary of the map images is presented which allows a GIS client to associate the image with the correct location on the rendered display.
For decryption, the client must use the information from the dek_info element. This is a JWT in compact decoding. After decoding, the following information becomes available:
{
"jku": "https://ogc.secure-dimensions.com/dcs/.well-known/jwks.json",
"kid": "Dr. No",
"alg": "RS256"
}
Header of the JWT defining the public key used for signature
{
"sub": "95d3827d-efef-3052-a2df-46d1c7ce77a5",
"aud": "019b7173-a9ed-7d9a-70d3-9502ad7c0575",
"kurl": "https://ogc.secure-dimensions.com/kms/keys/15517e95-c764-4602-9e09-7aaad104d480",
"kid": "15517e95-c764-4602-9e09-7aaad104d480",
"iss": "https://ogc.secure-dimensions.com",
"exp": 1633098986372,
"alg": "A128GCM",
"iat": 1633096986372
}
Payload of the JWT describing the key’s metadata
Important information for the client is the kid or the kurl which can be used to fetch the actual decryption key from the KMS. The elements sub and aud can be used to verify that the key is actually designated to the acting user (identified by the sub) and the application itself (identified by the aud). Additional information when the key was created (iat) by whom ( iss) and expiration (exp) can be used to test applicability and fitness of the key.
The actual key that corresponds to the kid = 15517e95-c764-4602-9e09-7aaad104d480 is illustrated in the following code listing:
{
"kid": "15517e95-c764-4602-9e09-7aaad104d480",
"alg": "A128GCM",
"kty": "oct",
"k": "4rE7puBVzdMeXpv1Z3eyHQ",
"issuer": "4bf1cb21-9ff7-f443-f736-70781d89d413",
"expires": 1633098786,
"issued_at": 1633096988,
"aud": "019b7173-a9ed-7d9a-70d3-9502ad7c0575",
"sub": "95d3827d-efef-3052-a2df-46d1c7ce77a5"
}
Decryption Key in JWK encoding
5.2.2. OGC API — Features JSON Container
The OGC API — Features service implementation returns a JSON encoded container with encrypted features plus relevant metadata. Different format values trigger different encoding for the metadata; the data is always encrypted. All response structures are described in the Data Centric Security ER from Testbed 16.