OGC Testbed-16: Data Centric Security Engineering Report

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

Data-centric security (DCS) is an approach that underlines the security of the data itself rather than the security of communication infrastructure such as networks, servers, or applications. DCS further embeds security and usage policy within the content. The DCS related work previously conducted in the Testbed-15 explains the motivation for DCS in geospatial environment as "the response to the possibility that an unauthorized user, who intercepts network traffic or hacks systems storing sensitive information gains unauthorized data access".

Testbed-15 explored the DCS essentials and evaluated basis data centric protection (encryption), security labels (metadata), and access control based on security access policies. The policy enforcement considered temporal and spatial attributes assigned to requested data sets and service consumers. Testbed-16 adds the JSON encoding for responses and introduces a dedicated key management server component. Testbed-16 work further allows content negotiation via new, proposed media types. Other aspects of the DCS concept, such as management and tracking, might be subjects of the future work.

A data-centric security model includes:

According to established theoretical models DCS relies on the implementation of the following:

These concepts should be considered as a key aspect of the whole information life cycle phases such as creation, processing, collaboration, storage, archive, search, and finally deletion.

In a DCS architecture the data sets are "labeled" with metadata. This is usually in form of a structured header having attributes which specify their security relevance and allow the application of security access policies on such data (RFC-7444).

Security Labels provide a mechanism for controlling access to information in security environments. Data objects are labeled with a classification, such as "Confidential", "Secret", or "Top Secret". Data consumers are given a clearance, using the same scheme. The core model of security clearance (access control) is that someone accessing information has a security clearance, that controls what information can be accessed.

A common metadata format (DCS container structure) is the starting point from which more attributes could be integrated into the metadata. This includes for example, a creation and validity period, the data taxonomy, or the identity of the person assigning the classification. The data structure to hold this information should be designed in such a way that new attributes can easily be added. For example, the inclusion for post-release protection ensures the data can be released for a number of days, after which the data cannot be accessed. Cryptographic binding of the classification metadata to the data ensures integrity of the label and the data.

Document ITU-T X.841 (Security information objects for access control - Fig.5) provides general recommendation for DCS Access Control. Protected information is represented as a message with a cryptographically bounded (confidentiality) label. On the client-side policy enforcement makes data access decisions based on the label, user credentials (security level), and specific policy assertions about access granting. Comments in blue color added to the original figure represents the Testbed-16 DCS specific implementation details.

The most relevant part of a security (confidentiality) label is the classification. Many security label schemes (like those used in the previous Testbed-15 and in this one) use the following classifications:

STANAG 4774/8 standards define the application of a confidentiality label. This is a structured representation of the sensitivity of a piece of information. Previous DCS work was primarily focused on exploring that aspect of DCS. A data originator security label example based on NATO STANAG 4774 is given in the listing below. Encoding is XML. Bound through cryptographic signature with an arbitrary data payload, for example a Geography Markup Language (GML) document, would label the document as "secret".

Although the task dedicated to the DCS did not mandate formal requirements in Testbed-16, this section lists informal requirements based on the OGC Testbed-16 Call for Participation (CFP) as well as the section Future Work from previous Testbed Engineering Reports.

Testbed-16 DCS Requirements

For this Testbed, the experiments advanced the DCS concept (with respect to the geospatial domain) to a high-level architecture similar to "Digital Rights Management" or DRM. DRM concepts allow for the creation, protection, and delivery/consumption of content in accordance with contracts put in place between the parties. Such contracts specify which content is available against predefined conditions, usually specified in a policy. DRM architectures make clear the distinctions between content author, owner, providers and consumers. Using a DRM platform, a client could order content. This content could be multimedia more relevant to this topic than geospatial data sets in GML or satellite imagery data. After receiving a payment or obtaining credentials elsewhere the service/client streams and encodes/consumes the content on the fly or downloads and encodes/consumes the content later (possibly several times during the key validity period). With inspiration from a DRM architecture, the Testbed experiments derived use case scenarios and specified component interactions.

An example of more detailed evaluation of DRM in the geospatial area could be seen in GeoDRM RM.

This motivation and the requirements put on DCS lead us to the following two use case scenarios:

Because the DCS protected data sets leave the security perimeter of the data owner and are hosted in a cloud and/or distributed via third party channels, the important elements to deal with when applying the concepts of data-centric security are the strength of the encryption key (the length of the key) and cipher algorithm for performing encryption/decryption. These factors (strength and algorithm) relate to the differences in how these scenarios use the data. While the Online Streaming of protected content requires the decryption on the fly, in the case of Offline Authorization the client caches the encrypted content. The client decrypts the content when needed in the offline scenario.

The next figure depicts a high-level TB-16 DCS architecture with respect to the more general DRM architecture as depicted on Figure 2 and used as template:

The figure represents a logical view, which roughly mimics the general DRM blueprint. The implementations are different for desktop and mobile scenarios. In the desktop scenario a DCS server provides protected content on request via an OGC compatible API. An encoder component is implemented inside the DCS service and it is basically irrelevant for this testbed. Mobile scenario on the other side puts the focus on the policy enforcement, decoding and visualizing of protected content on mobile devices with respect to the user rights and policies associated with data sets. Therefore, the function of the encoder was performed by an external tool, which was used to prepare the content for TIE execution. Protected content resides in a cache on a mobile device. The mobile scenario demonstrates the interaction with KMS and content visualization on a mobile device after decryption was performed in accordance with user roles (security levels) and (GeoXACML) policies in the GeoPEP component.

The following components, listed with their essential features, are part of the Testbed-16 DCS architecture (in both scenarios):

Information security can be applied either on the infrastructure (perimeter-security) or in a data-centric fashion. While infrastructure/transport oriented security standards are integrated in communication infrastructure like in TLS 1.3, DCS is fully independent from the underlying communication infrastructure. This is important because (in many security critical applications) the stakeholders cannot rely on the security provided by communication channels (like TLS). With other words, data owners need to remain in charge of data securing when they are distributed in cloud-based resource services. Thus, it appears reasonable to incorporate security concepts in the data sets, which urges expanding the existing data structures for additional elements to carry encrypted data and artefacts such as metadata, security labels, signatures, etc.

In protocols with application-layer intermediaries, channel-based security protocols protect messages from attackers between intermediaries, but not from the intermediaries themselves (not from, for example, malicious applications running on the platforms of intermediaries). These cases require object-based security technologies, which embed application data within a secure object that can be safely handled by untrusted entities as it was described for JSON encoding format (RFC 7165). Data-centric security advocates generation, storing and provision of security related metadata and content such as security tokens (digital identities), policies, keys, signatures, encrypted content and schemas.

In the geospatial domain, data centric security is applied on data encoded using geospatial domain specific grammars (schemas) such as GML or GeoJSON. GML is an XML encoding while the GeoJSON format is encoded in JSON. The previous work in Testbed-15 regarding the DCS was based on GML and the container structure required for DCS was encoded using STANAG 4774/8 and XML binding.

JSON (JavaScript Object Notation) is a well-known XML alternative and widely used data-interchange format. GeoJSON was created as a response to the popularity of JSON encoding format and as an alternative to previously established GML format based on XML and XML Schema. GeoJSON defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents. RFC 7946 is the current GeoJSON standard.

Additionally to new DCS container formats, new HTTP Accept header content types are proposed for content negotiation. The Accept request HTTP header advertises which content types (container formats) the client is able to understand, which is important for interoperability.

If the security is required to be applied in the data-centric fashion, an additional data structure needs to carry signature and encryption artefacts. This includes the metadata related to a data origin identity, access rights/policies, and optionally data structure/taxonomy. Two encoding options for data centric securing of (geospatial) content are available. These are XML-GML and GeoJSON based encoding standards with corresponding containers. Two set of standards, NATO STANAG 4774 and STANAG 4778 (short STANAG 4774/8) and JWT/JOSE were chosen to implement the required container structure. Additional DCS containers and encodings require new media types to describe all useful combinations of data/container encoding and applied security functions.

To enable data exchange and interoperability among NATO Member States, NATO STANAG 4774 and 4778 define a syntax (4774) for trusted security labels / markings and how these are cryptographically bound to data objects (4778) to ensure the integrity of data and the label. Trusted security labels include, for example, data on the creator, creation and expiration date. There are different profiles for REST, SMTP, or SOAP, XMPP or Office Open XML. JSON binding is not supported.

Beside standard security labels like classification, creator or creation and expiration date, in the geospatial domain additional metadata about the spatial scope of the data set is frequently relevant. For example, large, encrypted sets of geographic entities having metadata labels containing a bounding box allow access policies, which constrain data usage based on user location.

For JSON encoded data mostly used in interactions via RESTful APIs there is a family of standards designed to implement confidentiality and integrity in a data centric fashion. These standards are based on JSON Web Token (JWT) and also includes the JWE and JWS specifications, which is known as JOSE. JWT is basically seen as the root specification, which the JWE and JWS were derived from.

STANAG 4774/8 was used to implement the Testbed-15 DCS architecture with trusted security labels. Currently, the standard fully supports XML binding. Other representations, for example in JSON, would be possible (JSON is currently not supported). The full STANAG 4774/8 data structure is depicted in the following figure:

The figure displays the container structure from testbed-15, which holds a key (symmetric) required for data decryption. The key is protected inside of the encrypted metadata section and can be extracted only if it were encrypted with the receiver’s public key, which means the encryption was performed using public cryptography (PKI). This approach has certain security limitations and inflexibility. In Testbed-16 that will be mitigated through a new component - the KMS responsible to issue decryption keys on request (for a given key_id encoded in a DCS container). Instead of encrypted keys, their identifiers (key_id) originating from the KMS will be placed in DCS containers.

Despite the fact that only XML binding specifications were provided for STANAG 4774/8 so far, there is another, (from the interoperability point of view) useful option - to introduce an equivalent binding in JSON for clients, services and APIs based on that technology. In such a scenario, JWS (encryption) and JWT (signature) standards (also called JOSE) are used instead of JSON-encoded STANAG 4778 content to ensure the integrity of the payload and security label, while STANAG 4774 will provide a blueprint for security label information and other meta-data of interests.

In the JavaScript/JSON ecosystem the communication is secured on a data level by applying a set of standards such as JWT and JOSE (combination of encryption and signature via JWS and JWE). The standards provide a structure intended to capture the metadata and artefacts required for standard security functions such as confidentiality and integrity. The following table gives an overview of the security stack based on JWT and JOSE:

A JSON security stack built around the standards listed above visualizes the relations between standards. While everything is encoded in JSON, JWE and JWS represent standard cryptographic operations related to encryption and signing while JWT deals with digital identities.

When Object Signing and/or Encryption (JOSE) is used to protect a payload, the resulting structure (as depicted on the figure below) establishes a type of container holding both the payload and the metadata. While JWS requires a fairly simple format to ensure the integrity, JWE requires additional attributes to support the confidentiality through the encryption. The payload could be any geospatial content, for example GeoJSON. The figure represents the container encoding with comma separated sections. An alternative would be to use a full, slightly more complex JSON representation.

For JWS the payload is first signed and enclosed in a data structure defined in RFC 7515. The structure has:

The header containing the signature metadata, the payload holds the base64 encoded protected content and the signature ensures integrity (or that header and payload are cryptographically bound to each other). The payload segment might also enclose the additional metadata information.

If the confidentiality of data is required, the plaintext data can be encrypted and wrapped up in a container structure based on JWE (RFC 7516). The container will have the structure according to the specification containing the following parts:

Ciphertext is the section where encrypted data payload (created out of original payload plaintext) is placed. Other segments such as initialization vector or authentication tag are populated according to the specification and in order to support data integrity.

The information to protect remains encoded following STANAG 4774/8 but in JSON (binding). The JOSE would provide additional cryptographic protection (ensuring integrity) for such a DCS container in JSON encoding. Following are the possible container forms or the combination of "JOSE for security implementation" and "STANAG to encode the meta-data":

The options are depicted in the following three figures. The green bar represents the overall information (data-centric container with all protection measures). Metadata as shown here is STANAG encoded in JSON: