WITDOM architecture


The architecture assembles several building blocks for enhancing the security of applications and organizes a number of protection components in such a way that applications can access them in a composable and modular way.

There are two trust domains in the WITDOM architecture, as illustrated in the Figure. The trusted domain is shown on the left. On the right is the untrusted domain, where services and data may be exposed to attacks, data leaks, and so on. The distinction between “trusted” and “untrusted” domains occurs according to the views, assumptions, and policies determined by a so-called end user of certain applications.
The end user is the entity that is ultimately responsible for running applications and for consuming their outputs.

All applications that run on behalf of end users in this architecture are hosted by the trusted domain. Applications can be deployed in the trusted domain without any special protection and they may benefit from application-specific services in the trusted domain. Applications access particular security-critical functions and services through a broker component, which mediates their interaction with the infrastructure.

Services may be provided by components in the trusted domain or by others in the untrusted domain. Typically considerations of cost, ease-of-use, and data sharing will motivate to host services in a (remote) untrusted domain. Application specific services running in the untrusted domain are called secured services whenever they satisfy the protection requirements of the end user. They will require some protection logic before and after the actual business-related processing.

Services correspond to processes that take a specific business role for the end users and could be provisioned using a Software-as-a-Service (SaaS) business model. The services residing in the untrusted domain require certain security measurements for protecting the data and algorithms with which they operate.

The WITDOM architecture is composed of a set of components as depicted in Figure.
Some components that are of generic nature and which could also be used for secure distributed systems with other goals. These are the “core components” (depicted in green).

  • The broker component knows about the locations of the various services, their deployment, how to access them, and so on. All services, whether in the trusted or untrusted domain, are registered with the broker. The broker is also concerned with matching the security preferences of an application to the security features offered by the services and protection components. In other words, the broker decides upon receiving a request from an application and in accordance with security preferences that a protection measure should be invoked. The broker consists of two elements, which run in the trusted domain and in the untrusted domain, respectively.
  • An identity and access manager (IAM) component provides functions for identifying applications and individuals (representing instances of customers or end users), configuring access control, and implementing authorization in the architecture. It mainly interacts with the other components through the broker, but they may also reach out to IAM directly, whenever there is a need for service-specific access control and authorizations.
  • A protection orchestrator (PO) mediates between the applications, the broker and the protection components (PCs), which introduce the actual protection measures, for example, by using cryptographic techniques such as masking or encryption. The PO coordinates the application of multiple different kinds of protection relying in a dynamic configured set of protection components using an application specific protection configuration.
  • Furthermore those protection components may rely on cryptographic methods which may require the use of cryptographic keys. The key management (KM) component will provision keys, certificates, and other cryptographic material for use by protection components in the trusted and untrusted domains.

Other components serve a specific security purpose. They are the “protection components” (PC) (in blue). These are responsible for providing techniques that guard these assets from attacks in the untrusted domain. The WITDOM protection components provide the following functions:

  1. Anonymization,
  2. Secure signal processing,
  3. Secure computation,
  4. Integrity and consistency verification,
  5. Data masking and desensitisation,
  6. End-to-end encryption (E2EE).

PCs will only process data that are in a common WITDOM format, stored in specific databases. Data coming from applications’ databases are first converted into the WITDOM format via a transformer component, which is able to transform any data that have the format of data used by registered services into WITDOM format.

The design of the architecture is aligned with the paradigm of a service-oriented architecture (SOA), which provides many benefits: extensibility, service re-use, flexibility, and loose coupling. It facilitates that:

  • A complex service can be composed as successive calls to individual services (disregarding of where they are deployed);
  • A service could be transparently (to the end user) moved from the trusted domain to the untrusted domain (only affecting performance and privacy levels);
  • Alternatively, a service could be provided in both domains, and the domain where it is finally executed may depend on rules or on parameters in the service call;
  • End users may develop their own applications that will make use of one or several of the services available without knowing anything of secure processing or underlying techniques.