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

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.

Figure 5 — OGC API Features returning encrypted features collection with metadata as JSON

For a response including digitally signed metadata, the f parameter must be set to application/dcs+geo.

Figure 6 — OGC API Features returning encrypted features collection with metadata as JWS

For a response including digitally signed metadata, the f parameter must be set to application/dcs+geo;profile=metaSign.

Figure 7 — OGC API Features returning encrypted features collection with metadata as JWE

For a response including digitally signed metadata, the f parameter must be set to application/dcs+geo;profile=metaEncrypt. The DCS server returns the encrypted metadata as JWE when the request includes the kek_kid which refers to the public key of the user, registered with the KMS. The DCS Server uses that public key to encrypt the cipher key used to encrypt the metadata. This is visible from the JWE header:

{
  "cty": "JWS",
  "enc": "A256GCM",
  "alg": "RSA-OAEP-256"
}

5.2.3.  OGC API — Features GeoPackage Response

The OGC API — Features implementation returns a GeoPackage with encrypted features as described in Annex A.1. This response type can be requested via the f parameter set to application/gpkg+dcs.

Figure 8 — OGC API Features returning GeoPackage with encrypted features plus metadata

5.2.4.  OGC API — Tiles GeoPackage Response

The OGC API — Tiles implementation returns a GeoPackage with encrypted tiles as described in Annex A.2. This response type can be requested via the f parameter set to application/gpkg+dcs.

Figure 9 — OGC API Tiles returning GeoPackage with encrypted tiles plus metadata

5.3.  DCS Client

The DCS Client implementation for the OGC Testbed 17 demonstrates the ability to request and ingest encrypted geospatial content using OGC APIs.

The actual Compusult implementation is realized using the Compusult GO Mobile Android application, which provides a standards-based geospatial and mapping solution for data discovery and visualization.

• Supports Android 5.0 (API Level 21) and above

• Supports many approved and draft OGC API standards (Maps, Tiles, Features, Styles, Images)

• Supports GeoPackage 1.3.0 and below

• Supports OpenID based authentication

• Supports The Key Management System (KMS) operations

• Supports decoding, verifying and decrypting JOSE and JWT content using Nimbus JOSE + JWT and Bouncy Castle

• Supports decoding and decrypting multi-part binary content using JCA and apache-mim4j

{
  "redirect_uris": [
    "http:\/\/www.gomobile_dcs.com\/oauth2redirect"
  ],
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code",
    "id_token",
    "code id_token"
  ],
  "client_name": "Compusult DCS Application - Mobile",
  "logo_uri": "https:\/\/www.compusult.com\/image\/layout_set_logo?img_id=12133&t=1615550967456",
  "scope": "openid profile offline_access",
  "contacts": [
    "aparsons@compusult.net"
  ],
  "tos_uri": "http:\/\/127.0.0.1:4711\/TermsOfUse.php",
  "policy_uri": "http:\/\/127.0.0.1:4711\/PrivacyStatement.php",
  "software_id": "4ef5dcfd-22a7-4947-a636-4a46a1cf8d43",
  "software_version": "1.0",
  "post_logout_redirect_uris": [
    "https:\/\/www.example.com\/oauth2logout"
  ]
}

{
  "client_id": "8d90bc42-4401-5f2a-9054-cb407a876ad8",
  "client_id_issued_at": 1629899374,
  "client_name": "Compusult DCS Application - Mobile",
  "client_secret": "...",
  "client_secret_expires_at": 1629928174,
  "contacts": [
    "aparsons@compusult.net"
  ],
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "jwks": null,
  "post_logout_redirect_uris": [
    "https:\/\/www.example.com\/oauth2logout"
  ],
  "redirect_uris": [
    "http:\/\/www.gomobile_dcs.com\/oauth2redirect"
  ],
  "response_types": [
    "code",
    "id_token",
    "code id_token"
  ],
  "scope": "openid profile offline_access",
  "token_endpoint_auth_method": "client_secret_basic"
}

5.3.2.  Client Authorization

The DCS client will require the user to authorize against any services that are known to contain Data Centric Security content. For OGC APIs compatible services this is determined by inspecting the format types available for request. For GeoPackages this is determined by checking the registered extensions. If a service/geopackage is determined to require authentication, a user is required to login.

Figure 10 — DCS Client — Authentication

Before authenticating the user is required to select the server they wish to authenticate against. The OpenID configuration is parsed and used to determine how to construct the appropriate authorization and token requests.

Figure 11 — DCS Client — Server Selection

After selecting the server, the user provides an authorization request including the registered client_id as well as the user specified code_challenge. An example authorization request will take the form of :

https://www.authenix.eu/oauth/authorize?scope=openid+profile+offline_access&response_type=code+id_token&redirect_uri=http%3A%2F%2Fwww.gomobile_dcs.com%2Foauth2redirect&state=xyz&code_challenge_method=S256&nonce=123&client_id=8d90bc42-4401-5f2a-9054-cb407a876ad8&code_challenge=14L0XjF8uRH5IPrEm8RfiPlZilPTFKwxvZqtD9NLxs0

The Client is then asked to select a provider, and provide credentials to authorize the user.

Figure 12 — DCS Client — Provider Selection

After providing the credentials an authorization response is returned containing the authorization code.

http://www.gomobile_dcs.com/oauth2redirect?code=bdc1634ddb2dd598327da3537064781948fd4ef0&state=xyz&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IkFTUHVibGljS2V5In0.eyJpc3MiOiJodHRwczpcL1wvd3d3LmF1dGhlbml4LmV1Iiwic3ViIjoiYzBmYjJlZWEtMTg1Ni0zNjczLTgwZmMtNzlkMGUxZWZkZmRiIiwiYXVkIjoiOGQ5MGJjNDItNDQwMS01ZjJhLTkwNTQtY2I0MDdhODc2YWQ4IiwiaWF0IjoxNjI5ODk5NTEwLCJleHAiOjE2Mjk5MDMxMTAsImF1dGhfdGltZSI6MTYyOTg5OTUwOCwibm9uY2UiOiIxMjMiLCJnaXZlbl9uYW1lIjoiQWRhbSIsIm5hbWUiOiJBZGFtIFBhcnNvbnMiLCJmYW1pbHlfbmFtZSI6IlBhcnNvbnMiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJBZGFtIFBhcnNvbnMiLCJzaWQiOiI2N2I1MDcwY2FmNzg2OWJlZjU2ZTZjZDAxNzlkOTQ3ZSIsImNfaGFzaCI6IkV0bjFYNzU3RFZQSks2djZETktOcVEifQ.gV44NNYQmdTI9FU6XwewecwzqfTbA3Pud_oRzFvI9cxnCyzQ5Kx5K7-utnJ5AdmsCzhxkuWyjz3nT9p6PfkywL9akdst58qhSjfNFAinnhIHfnHl_GUvm3vBNXhTxR7tJxzhrm5vycdGnHx2bLej_Awk-wRLncGyWGBn_kRJdePncYO78kBK3A4becIMGXkX8VDTO2Xx3vsrmmEx7NIam9RIN2s4P_nGpgtYfGw5dX1qv2nFP6D2d9JbgoCsqqcfLCs0arktRZepSE4pAwbmzhKNd1rRCnIscNZsw3nOmNrIbXGkCPfizG-ZfROP0zLRWq4JSrORX6uCFxfzyBhlPw

The authorization redirect URL is handled by the app, and prompts the user to allow the application to ingest the response. Note the user is asked to select the appropriate app one time, and all subsequent requests afterwards are automatically redirected.

Figure 13 — DCS Client — Redirect Selection

After selecting the app to handle redirection, the application retrieves the authorization code and uses this code to retrieve a valid token for use for the following url : https://www.authenix.eu/oauth/token. Basic Auth request headers are added to the request using the client_secret supplied by the user.

code=bdc1634ddb2dd598327da3537064781948fd4ef0&grant_type=authorization_code&redirect_uri=http%3A%2F%2Fwww.gomobile_dcs.com%2Foauth2redirect&code_verifier=Hlp9DyvxEm0XPxnsb3Mjuut77nI7oHwO57nEuaejxsMwgdKBqeKV6BYdq-lEd2tk_htpdj67u2otTShpws20sw

The server responds with a valid token response. The response contains the access_token required to be used with the KMS and OGC APIs.

{
  "access_token": "741e31abc7c6ec5444036b94fca79796b0925e09",
  "expires_in": 1800,
  "token_type": "bearer",
  "scope": "openid profile offline_access",
  "refresh_token": "c0ea4ca04432f47af977374a94dc8dc6e8b41f31"
}

If the request was successful, the client is then re-directed and updates the Authorization button to indicate authorization has been successful and that the client can now be used to request Data Centric Security content.

Figure 14 — DCS Client — Authentication Success

5.3.3.  OGC APIs

The DCS client supports ingesting and requesting OGC API services including Tiles, Maps, Features, Styles and Images. Given an OpenAPI definition file the client auto-detects the capabilities of the server and provides the user with options to change formats and styles, as well as downloading GeoPackage content on a service and layer level. For this testbed the following services were utilized:

• OGC API — Features

• OGC API — Maps

• OGC API — Tiles

5.3.3.1.  OGC API — Features

The DCS client reads the OpenAPI definition for an OGC API — Features service and through successive calls to /collections/{collectionId} produces a service with all of its required metadata for requesting content, including available styles and formats.

Figure 15 — DCS Client for OGC API — Features implementation

To request Data Centric Security content a user must select one of the available DCS formats. After selecting one of the appropriate formats, the client ensures the user is authorized and adds the appropriate request parameters/headers to request the encrypted content.

Figure 16 — DCS Client — OGC API Feature Formats

After receiving the content the client determines the data content-type by decoding and decrypting the data_description.

  "data_description": "eyJqa3UiOiJodHRwczpcL1wvb2djLnNlY3VyZS1kaW1lbnNpb25zLmNvbVwvZGNzXC8ud2VsbC1rbm93blwvandrcy5qc29uIiwia2lkIjoiRHIuIE5vIiwiYWxnIjoiUlMyNTYifQ.eyJ0eXBlIjoiRmVhdHVyZSIsInByb3BlcnRpZXMiOnsibmFtZSI6InBvbHlfbGFuZG1hcmtzIiwibmFtZXNwYWNlIjoiaHR0cDovL3d3dy5jZW5zdXMuZ292IiwiY29udGVudF90eXBlIjoiYXBwbGljYXRpb24vZ2VvK2pzb24ifSwiZ2VvbWV0cnkiOnsidHlwZSI6Ik11bHRpUG9seWdvbiIsImNvb3JkaW5hdGVzIjpbW1tbNDAuNzMwNjQ3LC03My45OTYwMzVdLFs0MC43Mjk5OSwtNzMuOTk2NDQ5XSxbNDAuNzMwNDM3LC03My45OTczNTZdLFs0MC43MzA4MzQsLTczLjk5ODA0N10sWzQwLjczMTE2NiwtNzMuOTk4NzZdLFs0MC43MzE1OCwtNzMuOTk5NTU5XSxbNDAuNzMyMTg4LC03My45OTkwNzldLFs0MC43MzI3OTUsLTczLjk5ODU1N10sWzQwLjczMTk4NCwtNzMuOTk2OTM3XSxbNDAuNzMxMzA0LC03My45OTU0OV0sWzQwLjczMDY0NywtNzMuOTk2MDM1XV1dXX19.fi4XeIgcMKurVsew3IewJpSXIH4n8TKs3SJpMsFCUQ0yteH6VSeT1qGNz4_PGADbWyCxOh4LZy8WB7tIR95PyIOix_D0cxS6YPI47k_eBDQ11WznyrHRs80iItXMCVxRr9o_eHevPVARts63fxg-x-esw9clhU4CexQEjPAOsT9ETAVjRgidSweS0Sva5INJ53BsYrhDiaR5at-dzuNI0BEoz-S8bCUF9KFgVBjnkA5mYbWNS7KNGd6htXoJoujdGaA1TfucRLLGlUJib6iL3wdnY5cplelyC9JO3MVnJjk4tsOFehtJ5KemBzFB59EROPjSDEET_Eub3fnY_VXA2Q"

After decoding the content, the header is used to retrieve the JWK and decrypt the content.

{
  "jku": "https:\/\/ogc.secure-dimensions.com\/dcs\/.well-known\/jwks.json",
  "kid": "Dr. No",
  "alg": "RS256"
}

The result is a GeoJSON feature which describes the features extents, content-type and other application specific metadata.

{
  "type": "Feature",
  "properties": {
    "name": "poly_landmarks",
    "namespace": "http://www.census.gov",
    "content_type": "application/geo+json"
  },
  "geometry": {
    "type": "MultiPolygon",
    "coordinates": [
      [
        [
          [
            40.87822,
            -73.926377
          ],
          [
            40.87042,
            -73.932477
          ],
          [
            40.874699,
            -73.938081
          ],
          [
            40.882078,
            -73.933406
          ],
          [
            40.87901,
            -73.924598
          ],
          [
            40.878978,
            -73.924506
          ],
          [
            40.87822,
            -73.926377
          ]
        ]
      ]
    ]
  }
}

After determining the content-type of the encrypted content a similar approach is taken to decrypt the data in the response. Here the header contains a KMS request that allows the user to reach out to the KMS service and retrieves the appropriate key given the user credentials.

{
  "iss": "https:\/\/ogc.secure-dimensions.com",
  "cty": "application\/geo+json",
  "alg": "RS256",
  "jku": "https:\/\/ogc.secure-dimensions.com\/dcs\/.well-known\/jwks.json"
}

After the decryption the client converts the GeoJSON features and renders the content on the map.

Figure 17 — DCS Client — OGC API Features — Manhattan (NY) Roads

5.3.3.1.1.  GeoPackage from OGC API — Features

The DCS client checks the available formats from the OGC API — Features service and determines if it supports requesting encrypted GeoPackages. If it finds the format of application/dcs+gpkg, an option is made available for the user to download a GeoPackage.

{
  "href": "https://ogc.secure-dimensions.com/geoserver/ogc/features/collections/tiger:giant_polygon/items?f=application%2Fgpkg%2Bdcs",
  "rel": "items",
  "type": "application/gpkg+dcs",
  "title": "tiger:giant_polygon items as application/gpkg+dcs"
}

Figure 18 — DCS Client — OGC API Features — GeoPackage Download

Once downloaded the GeoPackage metadata is read from gpkg_contents and the GeoPackage service is generated. The gpkg_extensions table is then read to determine if the GeoPackage is a Data Centric Security compliant Feature GeoPackage based on the extension_name sd_dcs_features. The encrypted format of the content can also be determined by reading the gpkg_data_columns table. See the GeoPackage DCS Features Extension for more details.

Figure 19 — DCS Client — OGC API Features — GeoPackage Service

The client then requests the feature content based on the map extents like any other GeoPackage Simple Feature layer. The structure column must first be decrypted to determine the content-type and the extents of the feature along with other metadata.

eyJraWQiOiI3MzBiMWJkOC0xNDE0LTQ2ZjAtOGRjMy02NzEzZjdlODZhZjgiLCJjdHkiOiJKV0UiLCJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAtMjU2In0.gxAXPp36uoNBC9WiTghy1sEgSG9iKwyYtaRGDunItQq5KmFKaOAUb06cBdnbOb2CvY3c-sAVPT-21VZ6F1fmjG1uUV_sLmRxdjiW7XZKs1T3hc-Zn9Oy4Ak-3iOTukdtv883j0q_fNMatTbdxWJh3tGRzTHMAwf_lVNmqo0fAYKilIr6160AN6QxF97gGVFqHKfvXzY2l7thJV9poQtGXi8_e31iAJEyj38m_XN91nXhuqocJxe4mWPifZuRa5B2LpVhw3BRSjLAVJ0mIZesKlUoQpM0Gn0HlaVGE4UGavize0KrLcKq34kWmt787_rAHfq9vlpL0b3rQn87J8pOUw.M_S4vt6kGIapv8SY.AUx5Tnq5s3fs8qbkjFGU0Zqg6qUKl2CjVfctOMrHE3O4szdiKlPDlMsO2mLWqiZPcyHdXVjIOGZ5769YHnMyQp8tN69WUc7crEMb19_WggaqUiYq8lFWeuNb2mjjylA1okuYMM0GZfEh6F0vqYIf2wLpw7mw28FMcfoO6v-sYThF0yDglUV3i0X0bDlU18uhgH1HNGyNsepEBg_Mj9i6hr9pcWeyb22iTNuKj7useXC6KRHrgzyWu8UeqJkQLFxGLo_kZuutjw3H-6_CRpPXAETb5MubJVCo05jISx1btnJu5UX8S8L5LjcXwBCpAKVL_eHOF_OnKersgnN-6H6FygtamS6RPkg_b9Fshtwny6LxsnaDNxG3tXMyMaB02qGBwaOMkTHijCY7tJWyvlR9kZI8jsxccTeWxncVGJ128ge2H3MR40V8rof2uIpuEP0zmP3maNQsKsJ0iCt49LfWANu2LAnjHkyxpwxXJbq3L5Zq3jkILFD8wL2bqaV1iGWltRZSLepyTDh0n_Eb1u9u7OCnLd-2EyKWfdbWPcHseiEhNb6u6RfHqC2xcLfnnA7ZTJIZH0tDDwhLASODhSvFfaolIkxda-3fd6IbaDh6S0r_IdH_Zlt6LObo6A7ESstFKUHiExT5YAKmM6FCg_t_BGt8jvVnxL9N-Xe94p77bnoPUDWYJv-y1yYRq4ExeJDuejv1uBbBnG0vLDxa7Hm8vwrNLcJVNeyUVtkwolEGdMZ1cg97geoKo7scQ85kJiZy6CBXaBcVl7Ou6ojuKPGY1Rx5KMzQ4aK3je8h9UKLfcyPcUUEl_uIbDxUB7yCTpuA6uKA-lbFiXSk2bEokGPdInTO8liLYWCoYqhn3NujJOnJ-RYuMdQ8yvOYWJGHKZFHD9Lbr1MnGPPhVFq0ZovOdvbLFTsEuWxSKJaM-9LfBPmFyuoEE2OZRN3dDtu_cBe7_KS7qriO3sltCPSK1-00Wehcxx4bXFCDC2arnCAMx0rMAtYJPhaL_p6ibkGPrApJWxs529MefgGi5WRe3ImOWOGEPHJDsXSiHIaGJudzE57QhQQp6fQTOZR-H8fLiuy_krC1ykJkeuGJX_Cpnr_nNnz2SHuiSr_Hve2piKI1JGzilU_PcIyv8fguiCk_XIjcDhioclcYSR99XYJ_scCSuntALoVMbMRVvI7dXHEKTPjOR-mZ6WVYPyClBe7OFd0EK6fdtyIDvNoaRX0DW2U8aeYE-1_fOg5F2EvO-wsEd7BgJ100C15ik_AsOYJjlHbkLhL5B246Z2A8dIillSE913XMKrEWcYf25SKVp1KEzDFFx9v193hZOZn4OB95DgVuqe23PWBzsexlwLGTdRpH4XoyLMzln81K6uoZXg.3ubTT3yYZBIInUOUFeKQWQ

The client then requests the encryption key from KMS using the information available in the header.

{
  "kid": "730b1bd8-1414-46f0-8dc3-6713f7e86af8",
  "cty": "JWE",
  "enc": "A256GCM",
  "alg": "RSA-OAEP-256"
}

After retrieving the key, the structure is decrypted and verified to ensure the user has permission to consume the content. Using the content_type property the client determines what type of data to inspect in the encrypted data column.

{
  "type": "Feature",
  "properties": {
    "name": "DCSD6E1C05C8A81C2AE74C7AEDEA5EC92C1",
    "namespace": "tiger",
    "namespace_uri": "http://www.census.gov",
    "content_type": "application/geo+json",
    "attributes": [
      "the_geom",
      "NAME",
      "THUMBNAIL",
      "MAINPAGE"
    ]
  },
  "geometry": {
    "type": "Polygon",
    "coordinates": [
      [
        [
          40.70754684,
          -74.01083751
        ],
        [
          40.70754684,
          -74.01083751
        ],
        [
          40.70754684,
          -74.01083751
        ],
        [
          40.70754684,
          -74.01083751
        ],
        [
          40.70754684,
          -74.01083751
        ]
      ]
    ]
  }
}

A similar process is followed to decode, decrypt and verify the data content containing the GeoJSON features. After decrypting the content, the GeoJSON is rendered on the map.

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [
      40.7075,
      -74.0108
    ]
  },
  "properties": {
    "NAME": "stock",
    "THUMBNAIL": "pics\/22037829-Ti.jpg",
    "MAINPAGE": "pics\/22037829-L.jpg"
  },
  "id": "poi.2"
}

Figure 20 — DCS Client — OGC API Features — GeoPackage — Points of Interest

5.3.3.2.  OGC API — Maps

The DCS client reads the OpenAPI definition for an OGC API Maps service and through successive calls to /collections/{collectionId} and /collections/{collectionId}/styles produces a service with all of its required metadata for requesting content, including available styles and formats.

Figure 21 — DCS Client — OGC API Maps Service

To request Data Centric Security content a user must select one of the available DCS formats. After selecting one of the appropriate formats, the client ensures the user is authorized and adds the appropriate request parameters/headers to request the encrypted content.

Figure 22 — DCS Client — OGC API Maps Formats

After receiving the content the client decodes and decrypts multi-part binary content based on its format type. External keys are retrieved from the KMS. These along with the applications stored private key are used to decrypt the content and metadata and display the images on the map.

Figure 23 — DCS Client — OGC API Maps — Manhattan (NY) Roads/Landmarks

5.3.4.  OGC API Tiles — GeoPackage

The DCS client checks the available formats from the OGC API — Tiles service and determines if it supports requesting encrypted GeoPackages. If it finds the format tilematrixset-dcs or tilematrix-dcs an option is made available for the user to download a GeoPackage.

{
  "href": "https://ogc.secure-dimensions.com/geoserver/ogc/tiles/collections/tiger:giant_polygon/map/giant_polygon/tiles/EPSG:4326?f-tile=image/png&f=application/gpkg%2Bdcs&multiTileType=tiles",
  "rel": "tilematrixset-dcs",
  "type": "image/png",
  "title": "tiger:giant_polygon tile matrix set as DCS GeoPackage"
},
{
  "href": "https://ogc.secure-dimensions.com/geoserver/ogc/tiles/collections/tiger:giant_polygon/map/giant_polygon/tiles/EPSG:4326/{tileMatrix}?f-tile=image/png&f=application/gpkg%2Bdcs&multiTileType=tiles",
  "rel": "tilematrix-dcs",
  "type": "image/png",
  "title": "tiger:giant_polygon tile matrix {tileMatrix} as DCS GeoPackage"
}

Figure 24 — DCS Client — OGC API Tiles GeoPackage Download

After selecting the layer to download and choosing to download a GeoPackage the client generates a request using the users access token and selected format type and projection.

https://ogc.secure-dimensions.com/geoserver/ogc/tiles/collections/tiger:poi/map/poi/tiles/EPSG:4326?f-tile=image/png&f=application/gpkg%2Bdcs&multiTileType=tiles&key_challenge=secret&key_challenge_method=plain&access_token=998abda1e387e99003c8a9ff5a314d1a51381b72&kek_kid=730b1bd8-1414-46f0-8dc3-6713f7e86af8

Once downloaded, the GeoPackage metadata is read from gpkg_contents and the GeoPackage service is generated. The gpkg_extensions table is then read to determine if the GeoPackage is a Data Centric Security compliant Feature GeoPackage based on the extension_name sd_dcs_tiles. The encrypted format of the content can also be determined by reading the gpkg_data_columns table. See the GeoPackage DCS Tiles Extension for more details.

Figure 25 — DCS Client — OGC Tiles API — GeoPackage Service

The client then requests the feature content based on the map extents like any other GeoPackage Tiled layer. The result is encoded metadata dcs_info, encrypted key information dek_info and the encrypted tiled images tile_data.

First dcs_info is decoded, and the header is used to retrieve the key. The parameter jku is used to retrieve the keyset and load it.

{
  "keys": [
    {
      "kty": "RSA",
      "e": "AQAB",
      "use": "sig",
      "kid": "Dr. No",
      "n": "kHGuPCEyY4adIpPgMuw7H5H5zh03eADvj_Tc12zFR3LavpAHrkC8XxGbdgXmknIfN2uV_jcg5uM4crbJGfqnS1elznJjAEZ3e1kwZOTKPiqGqrL-6DgvFjLgdh8JcT95z1Q5MIO7u9-Ru-YR-DxXQzYN9Pq3lee8VmaRSRICLgvi9D08m2GwUvIlerac2WG04xB4FbFw7NuiDoQEAHuppTK6aWusiiOSwd31Nvg6b8Ein4nFyhxGMaZKrtegpnUa5eZZdKetzzvsCcRP_4pt5rjOof46jjjM_YbRd0IIyIq0vufGogB_C5yndIQa2odcY2_rVEayqKFBu2VuFGSmtw"
    }
  ]
}

The key defined in the header is then used from the response to decode the JWT content.

{
  "originator_confidentiality_label": {
    "confidentiality_information": {
      "policy_identifier": "TB17",
      "classification": "Top Secret"
    }
  },
  "data_producer": {
    "origin": "Not NGA",
    "date": "2021-08-25T18:38:23.957Z"
  },
  "tile_information": {
    "zoom_level": 14,
    "tile_column": 9647,
    "tile_row": 4486
  },
  "data_information": {
    "hash_alg": "SHA-384",
    "hash_value": "c5c48da9f073c0a0e477d5d7bced25c81e5dc0258b670d9450b33f96275a9f66fea6c81b1ef3475695144e07f547ee11"
  }
}

A similar process is followed to decode the JWS dek_info using the key defined in the header to decode the payload resulting in the decryption key required for the data.

{
  "sub": "c0fb2eea-1856-3673-80fc-79d0e1efdfdb",
  "aud": "8d90bc42-4401-5f2a-9054-cb407a876ad8",
  "kurl": "https:\/\/ogc.secure-dimensions.com\/kms\/keys\/c2e5dc56-b14b-4f28-8e72-a78779271744",
  "kid": "c2e5dc56-b14b-4f28-8e72-a78779271744",
  "iss": "https:\/\/ogc.secure-dimensions.com",
  "exp": 1629918,
  "alg": "A256GCM",
  "iat": 1629916703949
}

The decryption key is then used in conjunction with the Java Cryptography Architecture framework to decrypt the image. The first 16 bytes are read from the data column and used as the IvParameterSpec input to the cipher. The result are decrypted tiles based on the format requested by the client.

Figure 26 — DCS Client — OGC Tiles API — Geopackage Landmarks (NY)

5.4.  Key Management System

The Key Management System (KMS) for Testbed-17 provides an API that offers the registration and fetching of Data Encryption Keys (DEK). The KMS supports key creation and key owners to specify access conditions for each of their DEK via portal pages, accessible after login. In addition, the KMS also offers an API for the registration of Key Encryption Keys (KEK) in order to encrypt responses that contain a DEK.

Figure 27 — KMS API in OpenAPI

5.5.  Data Encryption Key Creation

A keys’ lifetime begins with its creation. This can take place in an encryption service like the DCS Server, offline or via the KMS admin interface. After the time of creation, no data has been ciphered yet and so the usage of the key is encryption. At the stage of encryption, the key might not be available for decryption purposes.

The following figure shows the KMS portal page for creating a Data Encryption Key.

Figure 28 — KMS Input form for Creating a Data Encryption Key

When creating a DEK via the KMS, the user must provide different types of information:

• PIN or secret that is required when adopting the access conditions of the key via the KMS Admin Portal.

• Audience is the UUID of the application that gets immediate access the key (if the Check to activate key option is selected). Additional applications can be added via the KMS Admin Portal). In the case where the DCS client shall be used for creating encrypted content based on the created key, the DCS client’s UUID must be provided. If AUTHENIX is used as the Authorization Server, the UUID of the application can be found here.

• Expires determines the initial expiration time of the key. The expiration time can be changed via the KMS Admin Portal.

• Cipher Algorithm is a list of symmetric ciphers as illustrated in Figure 29. The top of the list is used with JWK and the list identified with URIs is used specifically for XML Encryption.

• Check to activate key option allows to make the key available immediately to the application specified above and until the expiration time.

Figure 29 — KMS Ciphers for Data Encryption Key

In case a key was created offline or created by the DCS Server, the key must be registered with the KMS as no protocol exists that would allow the direct exchange of the DEK between the DCS client and the DCS Server.

5.6.  Data Encryption Key Registration

The KMS offers an API for the (automated) DEK registration. The KMS API supports different options:

• the DEK can be uploaded via HTTP POST and the KMS created the key’s identifier (kid in JWK terminology) via the DEK/addKey operation

• the client application creates a UUID based identifier for the DEK and uploads the key via HTTP PUT to a URI including the key’s identifier via the DEK/addKEyById operation. In case that another key with that UUID already exists, the response is HTTP Conflict.

The HTTP response to the POST and PUT operation will contain the key identifier(s) that can be used with the GET operation to fetch the key details including the key’s secret.

5.7.  Data Encryption Key Deletion

A DEK can be deleted from the KMS via the DEK/delKeyById operation. Compliant to the NIST 800-57 recommendation and to ensure that key identifiers are unique, the HTTP DELETE option does delete the key’s secret and deactivates the key so that is can no longer be fetched via the KMS API ( the KMS will return a HTTP GONE if the key is requested after the deletion). Even though the key could still be reactivated via the Admin Portal, it is useless as the secret (k) value is set to NULL.

5.8.  Data Encryption Key Access Management

Once a DEK is registered with the KMS, the owner of the key can modify the access conditions after login. Key ownership is identified via the PIN that a user submitted when creating a DEK via the portal pages or the DCS client submitted with the request for encrypted content via the key_challenge parameter.

The user must login to the KMS for viewing and adjusting access conditions to their DEK(s). Once logged in, the KMS displays a list of all keys accessible to the user (see Figure 30).

Figure 30 — KMS Showing list of “my” keys

The user can open the access management page by clicking on the link for a particular key. As illustrated in Figure 31, the use has different options to constraint access.

Figure 31 — KMS Access Management Page

• PIN: In order to change access conditions for the key, the user must provide the PIN. The blue ? can be clicked to check if the PIN is correct. If so, the icon will change to a green check-mark; if incorrect, the icon will change to a red X.

• activate: The activate option controls whether the key can be requested via the DEK/getKeyById operation at all. If unset, the key cannot be fetched from the KMS, regardless of the conditions specified. This is a kind of emergency override to stop release of the key.

• shared via email: The next option allows to make the key available to users based on their email address(es). Please note that the email address of a user depends on the login provider chosen when logging in via AUTHENIX. If the OGC IdP is used for login, then the email address is equivalent to the email address shown in the OGC Portal; if logged in via Google, the user’s Gmail address must be used for sharing.

• shared via user Id: In case that the key shall be shared with user(s) but the users do not want to provide their email address(es), the user can provide their UUID. The UUID is displayed once logged into AUTHENIX. The user’s identifier UUID is displayed at the bottom of the page. It is the value for the Sub attribute name. This honors the privacy of the users as coined in European Union’s General Data Protection Regulation (GDPR).

• shared via application Id: Any application that needs to obtain a DEK from the KMS must first be registered with AUTHENIX and the client_id UUID from the registration result must be put into the application UUID box. Any application that is currently registered with AUTHENIX can be found following the Operators link. For example, the OGC Token App used for various demonstrations has UUID 019b7173-a9ed-7d9a-70d3-9502ad7c0575 and the DCS client that supports decryption of GeoPackages with Encryption Extension has UUID 8d90bc42-4401-5f2a-9054-cb407a876ad8.

• temporal conditions: Next, the user can specify the time window of access. The from time can be set to the future which is an important feature if encrypted data is packaged on some mobile devices and they are shipped to their final destination. While the devices are in transit, the associated decryption key cannot be accessed.

• spatial conditions: In addition to the temporal conditions, also geospatial conditions can be added. The selection of multiple polygons allows access to be constrained to particular areas. This ensures for example that mobile devices can only obtain the decryption key if within the ‘green’ area.

The registration and fetching of DEKs require that the request contains a Bearer access token issued by AUTHENIX. From the Bearer access token, the KMS determines the acting user (sub) and the application that issued the API request (aud). These two pieces of information are essential key access conditions.

6.1.  TIE Setup

Common to all tests is that the DCS Server provides the DCS capabilities “on top” of regular OGC API requests by requiring the calling application to submit additional parameters:

• OAuth2 Bearer Token as specified in RFC 6750. The bearer token identifies the acting user.

• key_challenge as specified for code_challenge in RFC 7636

• key_challenge_method as specified for code_challenge_method in RFC 7636

• kek_kid or kek_uri as specified in Annex Clause 5.2: A private RSA key previously registered with the KMS.

6.2.  DCS Server Tests

This section introduces tests for validating manually that the DCS Server responses are as expected.

{
    "type": "DCS",
    "objects": [
        {
            "metadata": {
                "originator_confidentiality_label": {
                    "confidentiality_information": {
                        "policy_identifier": "TB17",
                        "classification": "Top Secret"
                    }
                },
                "data_producer": {
                    "origin": "Not NGA",
                    "date": "2021-08-31T10:22:37.537Z"
                },
                "data_description": {
                    "type": "Feature",
                    "properties": {
                        "name": "poi",
                        "namespace": "http://www.census.gov",
                        "content_type": "application/geo+json"
                    },
                    "geometry": {
                        "type": "Point",
                        "coordinates": [
                            -74.0104611,
                            40.70758763
                        ]
                    }
                }
            },
            "data": "eyJpc3MiOiJodHRwczpcL1wvb2djLnNlY3VyZS1kaW1lbnNpb25zLmNvbSIsImN0eSI6ImFwcGxpY2F0aW9uXC9kY3MrZ2VvIiwiZW5jIjoiQTI1NkdDTSIsImFsZyI6ImRpciIsImt1cmwiOiJodHRwczpcL1wvb2djLnNlY3VyZS1kaW1lbnNpb25zLmNvbVwva21zXC9rZXlzXC80Yzk4ZmEwYS1hMjEyLTRkNmEtOGNlZC1kOGNiNWQ2YjJlN2UiLCJraWQiOiI0Yzk4ZmEwYS1hMjEyLTRkNmEtOGNlZC1kOGNiNWQ2YjJlN2UifQ..LONNO9mf_oqXGEvY.l3axe9IMILYX-mvIy-3MTUYh_PT-9KAwAdjXOlFsP9DiDdhbEeaOWOiJiDF30PM6rHw4uA7to-HYCdusIqNjKU4fQkEKDLxJnE47jlmFS4zWQoIbnWvZpcIr4HD1hmIsa8dsMrccNqifwn_YpQpSEtQh8H1-4k_GIt7M9lBvQUYVsRcauAJhOXaMMB7L-47_ZiqRWAW08Bpe3wA49FjbSzbs0oUGgYl6d9O6eG3c5eZEE2tFvQlmfJLLvEi6bMu_65adbq4KEIBC7UuXHQgi7v-JLzhNIh_5CXDlpqQcT3xz6wno81r-EnLrqSjNDsLxwLd5Z3Mi3-ZzsDIBiHGG0TlfWFIqKtl6G-sPdr0DHkpVXYZTh3FOVgejwckXITo3vlaDdVcTUtXvAvxNRdtnUgWEItOOy3vCRggyrFfFlD9YMq5JzjOilCU1JMdrsgWgUpDj3XFfDp6YqVvj9ynNI6pK3iiwQ4U_m7_riM_p_XOkmrvCCgNbm3LJJADoXc_33S0e-xKHcwZ08PDgqK2H23RHBdGyIgh-yvcohHBeqc3hQMKcSPMkYb6nPIRVMY6Vk6fUvyYjBZUyP7CMk09DfLjSTBd1qfbjyVQpwgVxdhdHLEiGVJqzK3sagRbqrTl9sKpOkhT_ziJH4UaPSNmnqDzYhuIBwqOGaM74wIIastKFjvOYnh67XdTKVfFRM7DUqZIjfkH3Yye6YT5fa8Flqzi6xdYhEWP7UhOJfUu_QLi6KFoh4cLfUU-Pc_r01HcGI0OGrVs4Xqgv4CP9atlAeGELWIHQnQITpUTioi3Fq6-AeFuBDcXlD_6k3bVX-nSRHIPqAsMgTpiwM0GZ0LFu2u22Lyq804MJ3MEcA-S6u4vj9ZO40QRbi3-DwIcSnwYLlCJN20e4p3V_h25JHOFzgmkBTVNyh2gdVzwHFUW2Km5jrAicJeCWUNp6bR0SflMmhFNVpuiZ6m8cI5qQAPqCsGTIEP334QCrxzbVRh1V0r7orhnOn7GIaEIOTn34AM7NH8vcJK6i98Szk5zZqoYvxzD1ph4UODvt1OH0LMrdHZd4w33Gc6UQ0JRx5-RUdS26x5saAv2Zi8APFyn9IrDgo_LXFWXOeyH_yMXfScnU-BcMs0Wc4uh-dHdS7r4.9NLNpMuwkd2MUINu4VBF2w"
        }
    ],
    "totalObjects": 6,
    "numberMatched": 6,
    "numberReturned": 1,
    "timeStamp": "2021-08-31T10:22:37.541Z",
    "links": [
        {
            "title": "next page",
            "type": "application/dcs+geo",
            "rel": "next",
            "href": "https://ogc.secure-dimensions.com/geoserver/ogc/features/collections/tiger%3Apoi/items?access_token=a7b05c5df39c47bb94148a1cdcf081876da54f50&key_challenge=secret&key_challenge_method=plain&f=application%2Fdcs%2Bgeo&limit=1&bustCache=0.7411873339750994&startIndex=1"
        }
    ]
}

{
  "iss": "https://ogc.secure-dimensions.com",
  "cty": "application/dcs+geo",
  "enc": "A256GCM",
  "alg": "dir",
  "kurl": "https://ogc.secure-dimensions.com/kms/keys/4c98fa0a-a212-4d6a-8ced-d8cb5d6b2e7e",
  "kid": "4c98fa0a-a212-4d6a-8ced-d8cb5d6b2e7e"
}

{
    "type": "DCS",
    "objects": [
        {
            "metadata": {
                "originator_confidentiality_label": {
                    "confidentiality_information": {
                        "policy_identifier": "TB17",
                        "classification": "Top Secret"
                    }
                },
                "data_producer": {
                    "origin": "Not NGA",
                    "date": "2021-08-31T10:33:42.957Z"
                },
                "data_description": "eyJqa3UiOiJodHRwczpcL1wvb2djLnNlY3VyZS1kaW1lbnNpb25zLmNvbVwvZGNzXC8ud2VsbC1rbm93blwvandrcy5qc29uIiwia2lkIjoiRHIuIE5vIiwiYWxnIjoiUlMyNTYifQ.eyJ0eXBlIjoiRmVhdHVyZSIsInByb3BlcnRpZXMiOnsibmFtZSI6InBvaSIsIm5hbWVzcGFjZSI6Imh0dHA6Ly93d3cuY2Vuc3VzLmdvdiIsImNvbnRlbnRfdHlwZSI6ImFwcGxpY2F0aW9uL2dlbytqc29uIn0sImdlb21ldHJ5Ijp7InR5cGUiOiJQb2ludCIsImNvb3JkaW5hdGVzIjpbLTc0LjAxMDQ2MTEsNDAuNzA3NTg3NjNdfX0.eQKyi9iy54OdUE6UghkAn5_51SYoELW2PaSnmECu7Kcb-gejQpd5KA5n1UplDqSJK-tq-xwOv1JqKI6mACPoD0DBZws296e1cRUMTv4vQt54BGJarJ3CCip7YMCbyYB1dUCRJi5Mr-wgw6JAdJpVBMCMmn4fIzvGLo3FxhzghoRsAEvte5vGOEBnG-K4SDrqvDIVDAlCHr_uibPNV3SnlZQZhY_R0iCjGiP2X5uOj9FXL3JFgDuteHoyLoiIfhH5yYosmJygAOgJeQbBKHZ3TR97sire4cq84Y51MP9eCd7-9wyoRzQISXbiUF22O0cmqtp-eX3NfiL3tam8RrA5LQ"
            },
            "data": "eyJpc3MiOiJodHRwczpcL1wvb2djLnNlY3VyZS1kaW1lbnNpb25zLmNvbSIsImN0eSI6ImFwcGxpY2F0aW9uXC9kY3MrZ2VvIiwiZW5jIjoiQTI1NkdDTSIsImFsZyI6ImRpciIsImt1cmwiOiJodHRwczpcL1wvb2djLnNlY3VyZS1kaW1lbnNpb25zLmNvbVwva21zXC9rZXlzXC8yODQ0NDM2ZS1jMzZhLTQ0ZmItODRjMy00M2YwMjk4OWVlN2UiLCJraWQiOiIyODQ0NDM2ZS1jMzZhLTQ0ZmItODRjMy00M2YwMjk4OWVlN2UifQ..yulhMbph5H97cOg1.cGRL7hAq1_-oyZvJ-erDcqtjluo-lgO6XcqHwLYVVFx-0HNd2fYmF4chihmUX2bgkMc_cNJ5FaiTuQXhQVkMmlfAyw2mRK6vAkEJO0X9jCQytbycR_lmG7hgiQF1MtXZEocyP73g748D-E38GLkJkEJHO0jKe7nOeBynHJjkN2zQD0lqznj4d5tMCpUxh71S13Bz3UDIGxdY-2QOZw9v7hJCnpRBvGKeMNZamgcK21LXtBBN3pfvsApZBsUvpW8ELNjyQlcZGSVD_QLwXWvoVXDKlcSep2pEltz5YVwgnhXasmBqjr-eq9rPU-4Aah9Q5F9CFFKGTpZtAS85lLqeNCBYAZUXkmYpX31cXZhbRTLuJfww3Sm8KAZGj4NxVV_aEPbNiQM7XaZMSRXPqN8tV2h0htU1Vs7XgZGnHRnoNB8gQHgynmi7gGlM49K35lWpP0pn_AKTS2lTRyCj9jkOoFZfxwv5G512vLzxtg5untsvyhUFHGOtF8vPPicG-hSTroO7qqbVbvPmVN5sZ1skuhyM18Axr1-GGwVb1QHyjH8I2QO7JBBmvxQ2led7nZPs6GbEkbv8y9YS1jY8A4DtTE767irKNvYEOBYM2ZeE3QMRQIw_d2LKm5XVOeRMIiXVOIr42MaAuo1f6QuE61ARmUg8oc_e9GBkIicMeoHLRu__VGUnoFjND6eCAuVo6gyz0fcDdTtCY9oQxVMgqy-xjEP4SEyOoj63d5rObUKdAgmFn9A6H5FF_97s5_u1KlXK8vBO0-mcpqFwgBF-UrDshoswTSVTjAx52Z_1Vc_-kUnUHBLz_WHfA9qaC2ljvy9XSWuFAWfvODuhSeDycJW6_VWJq8ueTCWwDjE2wD4oi6dsJ1jNSaHzxvykerR-5Hd1_B1xfD3hg7RpCyw07zKnbr2X8PZBRK51D0vLU-KyLRbQXMfW-j6RbLCtOS_9_wcGxZmsjOsQyy9_2dONzx5ojxyiUsLjsOgqtB0gnx8M_mZL-QS34fwSs5MT-IZNdm4IkO60j-iw-IQGBEjtO8YhThzKfilOikLpTM7KdAydlzFvlKcYqNTbAE8HbXQSxTKZ2fNi8DhVzucRgTTvOlQ3GpeDYPtwo2YLNjO0R5tWQor6-KW5Q9vv8rprFTY.cEe9OC7lP3qlvc_q3WZAaQ"
        }
    ],
    "totalObjects": 6,
    "numberMatched": 6,
    "numberReturned": 1,
    "timeStamp": "2021-08-31T10:33:42.961Z",
    "links": [
        {
            "title": "next page",
            "type": "application/dcs+geo",
            "rel": "next",
            "href": "https://ogc.secure-dimensions.com/geoserver/ogc/features/collections/tiger%3Apoi/items?access_token=a7b05c5df39c47bb94148a1cdcf081876da54f50&key_challenge=secret&key_challenge_method=plain&f=application%2Fdcs%2Bgeo%3Bprofile%3DmetaSign&limit=1&bustCache=0.7067005135391409&startIndex=1"
        }
    ]
}

{
  "iss": "https://ogc.secure-dimensions.com",
  "cty": "application/dcs+geo",
  "enc": "A256GCM",
  "alg": "dir",
  "kurl": "https://ogc.secure-dimensions.com/kms/keys/2844436e-c36a-44fb-84c3-43f02989ee7e",
  "kid": "2844436e-c36a-44fb-84c3-43f02989ee7e"
}

{
  "jku": "https://ogc.secure-dimensions.com/dcs/.well-known/jwks.json",
  "kid": "Dr. No",
  "alg": "RS256"
}

{
    "type": "DCS",
    "objects": [
        {
            "metadata": {
                "originator_confidentiality_label": {
                    "confidentiality_information": {
                        "policy_identifier": "TB17",
                        "classification": "Top Secret"
                    }
                },
                "data_producer": {
                    "origin": "Not NGA",
                    "date": "2021-08-31T10:43:16.005Z"
                },
                "data_description": "eyJraWQiOiI4NTlmMjJiNC0xY2UxLTQyYzAtODY2OC1hYWM3ODljNzkyNDIiLCJjdHkiOiJKV0UiLCJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAtMjU2In0.Xyyi-3P38QPvtTS5z7gQ_II_Br88uXHWLzn5zoCYFEYXljBp73v3syBUvpRRh6N_ihZLlH8rAI4aJ34pEDS9vn4ufdsp7wbJdSXojT0d-YA1-LZ3VtvUiz5VeGyLKD5njqaGoGm_xXc-hM8L4PTbIlgTul_h2OWbyAEGgeRIGpcS5dqLEjb8sA8E0bZF4hsugGKOCvv0nyciWOVzH1VzSlepUa1DerqY7uKtLCwdO7QeUnjZQUGLijU0tETYzyMl8WkzIitK_y8Ui6ZyEn_NQDvPymilJK5kGfNFGO807GHIjJToTFOCD0X_Huew4x8pHCKcj5orMMfUr-nmTaL6Hw.kX3q83LN7MVAw4oq.hacw3EBp0mY3rCfoyBR5bWCAW_YsA_IujwIMZwPhpyfHrCeTufZWU-rgv1kPsT10ZmQZ67RuZN7S-ci3B7d9Mv2hr74TUOpzgrKMsaT4ow4jOiE-rAJj48dOb1JkVEd9QbpDPpZH5xO4H4br0AKsO6kQh68Wa_wQOvlsRbAWu99ImuUpZ0XswoAulgmDPdOOBHPrBbEDurH4o_s7ih84KsZa5X8OOzDetnJOfzQsTVesvRMi3VltfX-Bkyape1dM8Dxddzzf7429oHWVxEnsJ2QQBJq1hexYSnVeHNk04KqN_BrzvDrYeR2B0Yin6oxEAFbxlFsBjc10kNoB1rGk-9DcirmeLI9Pn9HlTgl_Dz-yOMX5P9h4tjEN7NnlU7YS1hU7YPJjIpKKgoff608E8KTDI0pyBnF8lkGnug4zt3mY7Qw1KMUPydvfe09lOJpXAiyWVBBf8HHqpPQk8jfl42GhwEQlN8uKGX6fni6AdGl3_92i4XwaHXdNnx3NQSjjD1VK4RoLUgBn4iIBmEMPPILuCc8Sg_rv5qnNhaMpLkyU5hMvzFcaLH9nZRGWO-iM7-uZ_rfA5oBPSpLYeROtjUQ3FIClGr0zFnuo-psphlpoqo3kDw5ZjB6QgrOOLQZmDc-yADGVDMXwDlucCWmIwOmEzDW1f84htkSdhdePH9SKYC1b54khXiUD4621txd8nJ7FZfuM2dgn_nHETYYJs36hYbwunXRnHia7vlCdZxxOefN7uE_WFVZ1suGC7v06ajXei2NSyV2ty6FVV72o2L5DcnglJ7rVMOxLkuz8oesx363m_b8eAm0pK_f3RdBVQ66bIF_EIUGYQ9udQMEJ0SgQO19pDGBMWKTMhQ5qXm-6t0Sa92qb6u_JIuchKBCcvn6RjFe0JV_H7-JaNkRfWV6PG9EgcyxOf30ZjoCYm66rJ-JWiMM9IiF03g4UA_SP9B-t8AUzbL0UUIK5Tg.bdy026MSYkNWFKIEAB74bw"
            },
            "data": "eyJpc3MiOiJodHRwczpcL1wvb2djLnNlY3VyZS1kaW1lbnNpb25zLmNvbSIsImN0eSI6ImFwcGxpY2F0aW9uXC9kY3MrZ2VvIiwiZW5jIjoiQTI1NkdDTSIsImFsZyI6ImRpciIsImt1cmwiOiJodHRwczpcL1wvb2djLnNlY3VyZS1kaW1lbnNpb25zLmNvbVwva21zXC9rZXlzXC85M2RmMjdjNi01MTc0LTRiMWQtYjY1Mi03MDRhNDJkNGRmMzEiLCJraWQiOiI5M2RmMjdjNi01MTc0LTRiMWQtYjY1Mi03MDRhNDJkNGRmMzEifQ..x4HVYSDjm6CqAVCd.xoaVF6G7aK4jMGkw9YFW_osVDlnB92eEBgqVVdsnwGE1-aHeVBas-xtnlptpN2pT2u59eG5Y9TZ9HerhlnClKkJyf3WVApkJXdGGbedsEefjIuaiJf-yYe6wYHXr-ZBq_ANHVRvbAru2pO2aZj1quvLhuG3YGt-pCX0IZ7R9c9E5l-MYxkU5jZtAJ8gQIHnkc7ZRrZls-VdwGrT7ogq0CVG4S_VG6vYwSh_iRdbY17n749DgISxSWh-n3sQ8o_Xp3OveeYrJjdxXYOE3ThLbRJHkgzZ-57VH7xL0kk3QJoGrJ0g8m6vrRcVY5EnUAXkUDvjtNfcRBnoFMf6BGDg5jFPfM3iMy3k1n8yXWKQ_fKsIdSjEkqEkE-YM-9pqH8qYI7ShC_wnlkyBaZI38cXA1FaUxj3D3O3uTEXmO7tyrBgMX_1R6NEQDyVRBZntOMhp0xyBprTxmG7823Nz1hgRQDd6rqqPPULqWIaq7NMXjc5nEyaMSkgU4cPgyRa7i3rPjdbNztOlUEVC5wdSNuHl1VoJQ8LRxkFokSo27DZfmky4pouaYqkmGh7C_k57D8tnJmsdEICV0VAXPukUCPh3hHtYnuvC0StFhcNJ9xmeI4hwDYxFPnvFUoIhUPJcv9jUXsNYk4QiX6b9dytLHLhmDbZwBjuGngCeNlOJjbra2YPcWp7Nv16EP7IPKoxARsbcnd1um1egw_1ncMgJoI5sT3wzu6sdHM9-RBt2VXU2QFhRnKWLhSK_t1Zg8VcY29c-dHdSuTq9KQuzAtpCG0HRLr27ZZO3SLLUL1BftRLSu-LxufthohDmg5gaB4WapgF2poevGDyzpPTYZ3GVuENWkTQdamCI1Wgu2lrKifgbaLTyWJpxx-nzyRNce9W7UWhRqGSd_diEqznEbgFfGJCqZOPpxm6jN7BvfWHqDI9F2t8G7GCrLAl55lh9Q8NOWvxFLiCCrc4m6IJQqjNQNWefLnjN7TLAj-SA4Xy9hz50KJPNIsEdGzotW_3a76CXd_C6hjs2uThersj5G3Kpt4Y-fgJv7g4oD5L8YiXK0264lr_Qy3lZbMUugRgO-MWWImbZ_i8D_JOYKIbn4Uoihyg5QHBh9t4QRRRYMDRLVdycpQOwVeNU9spSUtG0xW0.g-nV2GyDYTNzTH0qLuBEQQ"
        }
    ],
    "totalObjects": 6,
    "numberMatched": 6,
    "numberReturned": 1,
    "timeStamp": "2021-08-31T10:43:16.009Z",
    "links": [
        {
            "title": "next page",
            "type": "application/dcs+geo",
            "rel": "next",
            "href": "https://ogc.secure-dimensions.com/geoserver/ogc/features/collections/tiger%3Apoi/items?access_token=a7b05c5df39c47bb94148a1cdcf081876da54f50&key_challenge=secret&key_challenge_method=plain&f=application%2Fdcs%2Bgeo%3Bprofile%3DmetaEncrypt&kek_kid=859f22b4-1ce1-42c0-8668-aac789c79242&limit=1&bustCache=0.5590496976910175&startIndex=1"
        }
    ]
}

{
  "iss": "https://ogc.secure-dimensions.com",
  "cty": "application/dcs+geo",
  "enc": "A256GCM",
  "alg": "dir",
  "kurl": "https://ogc.secure-dimensions.com/kms/keys/93df27c6-5174-4b1d-b652-704a42d4df31",
  "kid": "93df27c6-5174-4b1d-b652-704a42d4df31"
}

{
  "kid": "859f22b4-1ce1-42c0-8668-aac789c79242",
  "cty": "JWE",
  "enc": "A256GCM",
  "alg": "RSA-OAEP-256"
}

Message-ID: 35d58964-dd70-4c99-b163-d4de161a48a1
Content-Type: multipart/encrypted; protocol="application/json"; boundary=ce5b9207-6e4b-4ba0-8632-9964aea0b927
Date: 2021-08-31T12:41:33+0100

--ce5b9207-6e4b-4ba0-8632-9964aea0b927
Content-Disposition: inline
Content-Type: application/json
Content-Length: 1420

{"metadata":{"originator_confidentiality_label":{"confidentiality_information":{"policy_identifier":"TB17","classification":"Confidential"}},"data_producer":{"origin":"Not NGA","date":"2021-08-31T11:41:33.062Z"},"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.eyJzdWIiOiJmZjEwNDVjMi1hNmRlLTMxYWQtOGViMi0yYmUxMDRmZTI3ZWEiLCJhdWQiOiIwMTliNzE3My1hOWVkLTdkOWEtNzBkMy05NTAyYWQ3YzA1NzUiLCJrdXJsIjoiaHR0cHM6XC9cL29nYy5zZWN1cmUtZGltZW5zaW9ucy5jb21cL2ttc1wva2V5c1wvYTJlNDNkMWYtMzc2MS00NTJiLWI1NWEtOWY1ZjY4MzA0YWZlIiwia2lkIjoiYTJlNDNkMWYtMzc2MS00NTJiLWI1NWEtOWY1ZjY4MzA0YWZlIiwiaXNzIjoiaHR0cHM6XC9cL29nYy5zZWN1cmUtZGltZW5zaW9ucy5jb20iLCJleHAiOjE2MzA0MTEsImFsZyI6IkExMjhHQ00iLCJpYXQiOjE2MzA0MTAwOTE4MjJ9.gFENFhsCc61ZbX4phIiUFXtMp7fWJigILbzUyfaSZaPfA1k-CuuHX975Ot4I3dLxvOLxerOlxIfUNnKJ9jHcZZUpxnZ5X0nyeYKt563ipKYnmCxptGz4C85dFskOvvRYHW1e4EHz3OlYWywUPPa4G4hGX7SysUz2YfB1XiPWeLYf1h_JP6lIofq_NeDklhYhq_LSQnFwYzSFnowAQZqlRswR6aUGeGFgPG2APX3J1Otx9vLJcQh0UxQG6O2gFxGyX54sv1z5mlqb3fUyjm5uJxJqfR7egcOTLYz6xco35ML4Bxnss22Us88qp2Ss87fRCGECLpxx8jzDHPk4AD3bng"}
--ce5b9207-6e4b-4ba0-8632-9964aea0b927
Content-Disposition: inline
Content-Type: application/octet-stream

t������e�����u�훺3
--ce5b9207-6e4b-4ba0-8632-9964aea0b927

{
  "jku": "https://ogc.secure-dimensions.com/dcs/.well-known/jwks.json",
  "kid": "Dr. No",
  "alg": "RS256"
}

{
  "sub": "ff1045c2-a6de-31ad-8eb2-2be104fe27ea",
  "aud": "019b7173-a9ed-7d9a-70d3-9502ad7c0575",
  "kurl": "https://ogc.secure-dimensions.com/kms/keys/a2e43d1f-3761-452b-b55a-9f5f68304afe",
  "kid": "a2e43d1f-3761-452b-b55a-9f5f68304afe",
  "iss": "https://ogc.secure-dimensions.com",
  "exp": 1630411,
  "alg": "A128GCM",
  "iat": 1630410091822
}

6.3.  Provisioning and portrayal of DCS protected geospatial binary content

The DCS enablement requires an extension to a standard OGC API request with additional query parameters. Depending on the API and the response format, different additional parameters are mandatory.

The following table illustrates which parameters are required:

Table 3 — DCS parameters (m=mandatory, o=optional)

6.4.  TIE Results

TIEs are conducted between the DCS Client Application (Mobile App) and the DCS Server. A successful TIE requires that the DCS Client and the DCS Server interact with the Authorization Server (AUTHENIX) and the Key Management System (KMS).

6.5.  TIE Summary

A successful TIE can be determined by the ability of the DCS Client to query, decrypt (and display) the encrypted DCS response from the DCS Server. When that is the case, all outlined interactions must have worked as a whole.

Table 6 — TIE Summary for DCS Client and Server

The successful TIEs were conducted between DCS Client Application and DCS Server.

7.1.  Overview

So far, the DCS solutions developed in Testbed 15-17 were demonstrated inside of an individual “Administrative Domain” (AD) that essentially comprised of:

• An Authorization Server that connects to an Identity Provider (IdP).

• A (Cloud) Service Provider (SP).

• A (mobile) client application.

• A user authenticated within the AD.

The relevant context of Federated Security is described in different (complex) publications:

• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.500-332.pdf

• http://docs.opengeospatial.org/per/20-027.html

The target architecture for supporting DCS with Federated Security is based on the Zero Trust Domain definition, where, in contrast to perimeter-based security, each interaction requires authentication and is subject to access control; literally trust nobody — verify all (users). With such a target architecture, where all interactions between a user-controlled application and secured services require authentication, there needs to be a solution for how to trust users that are authenticated in another domain. This implies the first topic to be analyzed: How can the existing DCS architecture be extended to support federated authentication?

As the Zero Trust can be coined to be data centric — each data flow is subject to being controlled — the question arises of how to establish such a control mechanism for encrypted data. With encrypted data, the typical access control approach no longer works, as the encrypted data must be treated as a BLOB or a black box. With data in the clear, the data itself can be used to derive fine grained access control, as it is possible with OASIS’s XACML or OGC’s GeoXACML. This challenge can be identified as the second important topic to be analyzed: How can access to encrypted (geospatial) data be controlled towards users authenticated in their own domains, as well as authenticated in another (federated) domain?

The overall question to analyze can be summarized as follows: “Is it actually possible to extend a single-domain DCS architecture to function equivalent in a Federated Security environment? Or, must limitations / constraints be defined that reduce the flexibility of the architecture with transiting towards federated support?

7.2.  Implications to Authentication

The existing DCS architecture causes all authentication to be performed in one single Authorization Server. Even though the Authorization Server in place (AUTHENIX) is based on federated identity management — it allows users to login with accounts from multiple domains — the Bearer Access Token linked to the user is validated with AUTHENIX. Also, the personal data that is linked to the access token can only be fetched from AUTHENIX. Extending the architecture from a single domain to multiple domains implies that either all domains trust the authentication to be done by AUTHENIX or that each domain operates their own Authentication Service.

At this point, the option that one Authorization Server operates as the only trusted authentication service can be ignored. So, assuming that each (Zero Trust) domain will operate their own Authorization Server, what implications to the remaining architecture exist? Each service in a Zero Trust Domain environment that provides access to data must be able to validate the (claimed) identity of the acting user.

One typical solution to extend authentication from one single to a federated infrastructure can be based on digitally signed assertions. These assertions can be either authentication, authorization or other security context statements. The OASIS Security Assertion Markup Language (SAML) is, for example, the backbone of federated identity management for eduGAIN, the federation of many academic institutions around the globe. In a nutshell, the setup of federated identity management requires to roll-out a PKI where typically Certificates vouch for the identity of an assertion. The assertion is trusted by the receiving party, if the digital signature can be verified to be from one of the trusted domains. Each domain operating an Identity Provider must exchange their X.509 certificate in advance. Applying such a concept to the existing DCS solution, the use of Bearer access tokens could be changed to Digitally Signed access tokens. The use of JWT, as described in JSON Web Token (JWT) is a possibility. Establishing a trust federation of Authorization Servers and what it all needs is described in OpenID Connect Federation 1.0 — draft 17. Comparing the approach with SAML, it seems that the principles are somehow identical, but the protocol is more modern: JSON instead of XML.

Another interesting effort is the one regarding W3C Secure Payment Confirmation where the objective is “…​ to scale authentication across merchants, to be used within a wide range of authentication protocols, and to produce cryptographic evidence that the user has confirmed transaction details.”

Any extension from one single authentication source to a federated variation has direct implications to access control.

7.3.  Implications to Access Control

When users reside in a single security domain, the authentication process can ensure that all user attributes become available that are required to undertake access control. However, when extending authentication into a federation, the access control decision, derived locally, might lack required user attributes. The cause of that could be that either the required attribute is not available at the other authentication service or that the attribute is simply not released to another domain. An example for the first case can be found when using the Testbed-17 Authorization Server and the login via the OGC Portal IdP. An authenticated user from OGC will have the OGC related claim ogc-is-member-of which is part of access control in Testbed-17. This claim lists all the user’s active OGC projects (DWG, SWG and project membership). When the same user uses Facebook, Google, or a University login, this particular claim is not available. Examples for withheld attributes can be found in the intelligence but also eduGAIN domain: user attributes that are considered sensitive (e.g. military ranking, personal information stored at a University) may not be released to other domains.

The other implication / complication to access control is the harmonization of access rights and their interoperable exchange. Based on the fact that in each Zero Trust Domain access control is done in isolation from other domains, how can it be ensured that one user gets access granted to a composite of services as required. As an example, a disaster management first responder requires access to information that is provided by services from different (Zero Trust) domains. There must be some (pseudonymize) unique identifier of the user that allows binding access rights in the local domain. This access control management objective has implication to authentication: All users — regardless of origin domain — must be identified via a globally unique identifier (unique and persistent across all acting authorization servers).

Assuming that each user can be uniquely identified, it is still possible that the user gets an HTTP status code 403 meaning access to the requested resource was forbidden. As the user is stuck in security, this message may not be particularly helpful. The resulting challenge is how to help the user or the application to “understand” what the issue is. This opens the challenge to know how much information can be exposed securely; remember: a Zero Trust Domain means “don’t trust anybody”. This implies that there won’t be any information available to help the user, as they are not trusted (and could be an adversary). But still, there must be some mechanism or protocol that helps to “bootstrap” a solution, assuming there was a legitimate request issued in the first place. Further analysis is required towards the question: How to determine the trustworthiness of a user in particular cross domain.

Another daring challenge is the exchange of access conditions among administrators of different domains for the purpose of harmonizing the access rights of users. The assumption is that the actual access control realization in each domain is done specifically, honoring different facets specific to the domain. But how can access conditions be exchanged with other domain admins to ensure that access requirements can be managed? Further analysis should determine how far the use of Access Control Markup Languages like XACML or GeoXACML help to (automatically) harmonize access conditions across domains.

Extending access control to encrypted data has implications for Key Management.

7.4.  Implications for Key Management

During OGC Testbed 16, a Key Management System (KMS) was developed to protect the data decryption keys used to encrypt geospatial data. The functionality of the KMS was inspired by the NIST Special Publication 800-57 Part 1, Revision 5, Recommendation for Key Management: Part 1 – General publication. In particular the key’s lifecycle and the separation of data encryption and key encryption keys was implemented. A Data Encryption Key (DEK) is the actual cipher key that scrambles the data. The possession of DEK enables decrypting the actual data. A Key Encryption Key (KEK) is a cipher key that is used to encrypt a DEK for storage or transit. Typically, a DEK is a symmetric key (shared secret) and a KEK is an asymmetric key (private — public key pair). In that regard, the use of the keys is different and so are implemented options for constraining access to the keys. Regardless if DEK or KEK, the key registration requires the user to authenticate. The registration of the KEK is limited to public keys. The assumption is that the matching private key is securely stored with the owning user. The fetching of the public KEK is open to all users as encryption based on the public key can only be decrypted by the associated private key. Further, per definition, their key is only in permission of the user. However, to prevent misuse in case the private key is leaked, the KMS supports the owner of the KEK deleting the key.

The KMS allows the owning user to apply fine grained access control to a DEK, as illustrated in Clause 5.8. However, the access control is not tied to the actual content that originally existed before encryption. For example, constraining access to encrypted information based on feature_type or classification is not possible via the KMS. Further analysis is required to determine how far the encryption process itself can reflect the original data’s characteristics. For example, the Testbed-17 DCS Server uses different cipher algorithms for data that is (artificially marked as CLASSIFIED, SECRET, TOP SECRET). However, the KMS does not constrain access based on the key algorithm. So, what seems to be missing is metadata on the usage of the key and which characteristics of the encrypted data exist that should be considered for access control to the DEK.

What are the implications imposed by federated authentication? The Testbed KMS relies on authentication from the single Authorization Server. Sharing of encrypted data, based on sharing access to the associated DEK can be based on the user’s email or unique identifier. But what is the user’s email or identifier in a federated setup? How does the KMS know which Authorization Server to contact if users from multiple domains are considered?

Assuming that each Zero Trust Domain wants to operate their own DC Server, what implications to the protocol between the DC Server and the KMS exist? What about the protocol between the DCS Client application and the KMS?

7.5.  Implications to the DCS Server

The Testbed-17 DCS Server offers requesting encrypted (geospatial) data hosted on a GeoServer implementation of the OGC Maps, Features and Tiles APIs. Regarding the encryption key, the DCS generates a DEK on behalf of the user. However, different options are possible:

1. The user requests encrypted content but leaves it to the DCS Server to generate the encryption key (DEK) on behalf of the user;

2. The user generates the encryption key (DEK), registers it with the KMS and submits the key ID with the request.

3. The user generates the encryption key and submits it with the request to the DCS.

For the first option, where the DCS Server generates the DEK on behalf of the user, the question is which KMS to use for key registration. To enable the DCS Server to register a key on the user’s behalf requires that the DCS server has sufficient access rights on the KMS. In order to refrain from complex access condition management across domains, perhaps the DCS Server should always register the DEK with the own KMS — the KMS operated in the same security domain.

The second option implies that the DCS Server can resolve the actual encryption key from the KMS used by the user. When not constraining which KMS that user could have registered the key, the DCS Server needs sufficient access to fetch the key. But, would a KMS release a symmetric key to a DCS Server? Assuming that a DEK is a symmetric key, it could also be used to decrypt data. So, a copy of the key stored at the KMS or exposed via an attack might jeopardize all data previously encrypted with that key. Perhaps a DEK never crosses security domains? Perhaps a DEK only can only be fetched by trusted applications? If so, how could applications verified to be trusted?

Regarding the third option, the DEK must be protected while in transit (the request is sent via the network). Even though leveraging HTTPS does protect information sent through the TLS channel, it leaves the URL in the clear. Therefore, submitting the DEK with a HTTP GET is “unwise”, even when the key is protected by a KEK. This brings an implication to OGC API standardization: OGC API Standards should support HTTP POST as an alternative to HTTP GET. Even though the use of HTTP POST over TLS would secure the DEK while in transit, but leveraging the transport level security mechanism is still against the philosophy of DCS: Apply security to the data — to the DEK in this case. Investigation of options applicable to protect the DEK when being submitted with the OGC API request is recommended. Is it possible / sufficient if the DEK is encrypted based on the public key of the DCS Server?

Would it be “wise” that the DCS Server accepts the (encrypted) DEK with the request? If so, would the DCS Server need to validate that the DEK actually belongs to the acting user? If not, a man in the middle attack might have replaced the encryption key with the own. It should be analyzed how a DEK’s origin (issuer and owner) can be verified in a federated environment.

7.6.  Implications on the DCS Client

The DCS Client for Testbed-17 implements the OAuth2 / OpenID Connect hybrid flow to obtain a Bearer access token from the single Authorization Server for the acting user. This access token is sent with each request to the DCS Server and KMS.

The implications of extending the single domain solution to a federated “mash” of Authorization Servers would impact the client application. The application would need to know which Authorization Server to contact for login. This complexity is currently proxied by AUTHENIX as it offers the login provider discovery (IdP Discovery). Would it make sense to implement such a complex and trust intense protocol as the IdP discovery into a client application? It is possible / recommended in the first place to think of Web-based, desktop, mobile and server-side applications.

When leveraging multiple Authorization Servers, how would the client application know which access token needs to send to which service endpoint? The proper matching would require that the client application knows which service accepts tokens from what Authorization Server. Is it wise to disclose all that information to the client application? Is this feasible?

What other approaches exist to lift the burden of access token and Authorization Server / Resource Server linking management off the client application?

For decrypting data, the client application must get access to the KMS. How can a key owner associate access conditions to the client application; it might have different identities with different Authorization Servers. How to not over-complicate access condition management? The more difficult the access condition management to keys get, the more difficult the validation of the effective conditions becomes.

7.7.  Implications to Security

The transition from a single source solution to a solution that works in a federated environment potentially introduces protocol vulnerabilities. How can vulnerabilities in protocols be identified to prevent or mitigate successfully attacks?

Potential security hazards must be considered when defining an interoperable protocol for a federated security DCS solution.

8.1.  Streaming-Ready Container Format

The GeoPackage container is a capable data storage format, but should not be created at the general user’s request. Further, when making a GeoPackage container available as an output format for a service on the Internet, establishing a resource quota is recommended.

Alternative encodings like ZIP are considered streaming-ready and do not produce a storage burden on the server. Future investigation into how far the use of a ZIP container format can be used as an alternative to GeoPackage should be considered. Perhaps the SQLite 3 ZIP extension can be used as a start. When doing this investigation, it should also be evaluated whether other alternative storage structures allow to create, store and distribute large amounts of multi-part, encrypted geospatial data in a more efficient way.

8.2.  OGC APIs and Asynchronous Responses

The current protocol for most (but not all) OGC API Standards requires that a HTTP GET request returns the resource as part of the response body. This can be characterized as synchronous request and response — the client and server are maintaining a TCP channel to exchange the request and response. In situations, where the production of the response takes a very long time or the size of the container is extraordinarily large (e.g. in Testbed-17 production of an encrypted GeoPackage for all Tiles from zoom level zero to twenty one took approximately 6 hours and required 21GB of storage). By the time the response was ready to be streamed to the client, the TCP socket was already closed. For Testbed-17, the DCS Server pushed the produced GeoPackage to a Content Delivery Network (CDN), where the client could fetch the response for the request at any later time.

An important response alternative could be that an API implementation reports to the client response will be ready in 6 hours - please go 'here (URL)' to fetch it. OGC API – Processes supports such asynchronous capability. Future work should investigate how other OGC API Standards could inform the client about an alternative location of the response. If an API implementation supports the persistent storage of previously requested resources (on a CDN), there could be a ‘smart cache’ at the API that redirects requests for previously created resources to their ‘persistent’ URL right away. Such a smart cache could reduce network and processing burden and improve response times.

8.3.  Authenticity and Integrity of GeoPackage

How can a GeoPackage container be made tamper-resistant or how far can Integrity be applied to a GeoPackage container (perhaps as an extension) that enables the consumer to verify that the actual copy has not been tampered with since its production. In addition to (or as an extension of) Integrity, it should be evaluated how authenticity could be applied to a GeoPackage. It seems strange that a DCS extension to GeoPackage supports storing encrypted (rows of) data but that the consumer cannot verify the origin and integrity of the GeoPackage container.

8.4.  Standardization of a GeoPackage Encryption Extension to OGC APIs

The results from Testbeds 15, 16 and 17 indicate that there is a common set of requirements that exists and defines a “DCS” Building Block for OGC APIs. However, in order to achieve an interoperable solution, the overall results from these Testbeds should be collected and brought forward as an Engineering Report, written as a Draft Implementation Standard. The OGC #17-007 OGC Web Services Security standard emerged in such a way.

8.5.  Direct Encryption to prevent unauthorized disclosure in Web-Applications

When the client provides the Data Encryption Key (DEK) directly to the DCS Server, it is possible to ‘simply’ encrypt the response with the provided key. This simplistic scenario is equivalent to DRM direct streaming and would apply to protect data from being captured by Web-Applications, like JavaScript based clients. In the content of (one-page) Web-Applications it should be investigated in how far the encrypted data can be protected for being captured in its original format to prevent unauthorized disclosure.

8.6.  Encrypted GeoTIFF and GMLJP2

Testbed-17 participants evaluated the options for packaging encrypted geospatial data into a GeoPackage container by defining suitable extensions (for Features and Tiles). The applicability of similar approaches for GeoTIFF and GMLJP2 should also be investigated along with the implications regarding the data and processing burden. If a solution exists, a standardization approach should be identified.

8.7.  Standardization of a Key Management System API

For Testbed-16 and Testbed-17, a Key Management System amended the DCS components. The main responsibility of the KMS was to create a symmetric cipher key, its registration if created offline, and the administration of access conditions. The implementation from Secure Dimensions, based on NIST 800-57, was proven to do a “pretty good” job. However, the API is not standardized. In order to ensure the productive use of Data Centric Security, the standardization of the KMS API is paramount.

8.8.  Sharing of a security context across administrative domains

For Testbed-17, a security context is exchanged with Bearer Access Tokens that are released and validated at one central Authorization Server. The Authorization server acts as the single trusted 3rd party to the DCS Server and DCS Client.

8.9.  Harmonization of Access Policies

Any Zero Trust Domain comprises of Authentication and Access Control, as illustrated in Figure 16 of the OGC Testbed-16: Federated Security Engineering Report. Even though the enforcement of access conditions must not rely on any standard, the exchange of access policies to facilitate policy harmonization across domains in a federated architecture should. Also, self-contained decision ready information GeoPackages with encrypted content should include the access policy that expresses — in a standardized fashion — the conditions for an application to decrypt and render the encrypted content. Further work should evaluate the latest work of the GeoXACML 3.0 standardization (see GeoXACML SWG for more details).