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)

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.

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.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!

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.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

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