The Data Protection Policy Specification Page

After launching the tool, as depicted in Figure 1, the default page can be seen, where the user can specify the architecture.

The menu bar includes the main options “POLICY”, “ARCHITECTURE” and “VERIFY”, for policy specification, architecture specification and conformance verification between them. More specifically, under the option “POLICY”, the user can specify a new data protection policy, save the policy, and open a saved policy.

Figure 1. After launching the app, the system architecture specification page can be seen.

Figure 2. The Policy Menu.

The policy page has three parts, the top part is to specify the entities/components in the system, such as authority, client etc. On the left side, the user is expected to provide a short notation, and on the right side, the full name/description to help identifying the meaning of the notation. The middle part in the policy specification page is for defining the data groups and data types.

As shown in the figure below, on the left side (PROVIDE A GROUP OF DATA TYPES), the user can define a group of data types. The option menu in the middle (called “IS THIS UNIQUE”) expects the user to provide if the data group together with its data types can be used to uniquely identify an individual.

Figure 3. The Archtecture Menu.

Finally, under the option “VERIFY”, we can verify the conformance between our specified policy and architecture.

Figures 4-5. The Archtecture Menu/VERIFICATION.

A policy can be saved in a file with an extension *.pol, while an architecture is saved in *.arch as can be seen in the pictures.

Add a main or sub component or a text box:

Change/choose the color of the components:

Draw an arrow between components and specify an action as the content of a text box:

Examples:

Example 1 (Without Cryptographic Operations):

A simple exampe on data collection and storage (in the context) of contact tracing apps.

An example verification result that shows the violation of the DPR and privacy conformance relations. In the policy, we left the data possession sub-policies for name, id and places empty/blank for sp, which means that sp does not have the right to have/possess any data of type name, id and places.

Specifying a data connection policy (e.g. here, we set that sp does not have the right to link/connect two pieces of data of types id and name)

In the architeture, the following actions are defined :

The verification result shows the violation of the DPR and privacy conformance properties:

An example verification result that shows the violation of the DPR and privacy conformance relations, but also some functional conformance properties (after in the policy, we give the service provider sp the right to have/possess ID and places). The architectural actions are the same as above, just the policy has changed as follows:

The verification result shows the violation of the DPR and privacy conformance properties, but there are two functional conformance properties:

Example 2 (Without Cryptographic Operations):

In this example, we present the receive action with metadata (information about other data) or "packet" header data (IP address, source, destination addresses, etc.).

In DataProVe this kind of information can be specified using the "Meta" construct.

The policy level:

In the policy we define four data groups/without data types in them.

Figure 8. Specifying data groups for the data protection policy.

Then, we forbid (any kind of likability, not only unique link) for the service provider to be able to link two pieces of data of types nhsnumber (national health service number), and photo.

Specifying the data connection policy. We forbid for the service provider to be able to link two pices of data of types nhsnumber and photo.

Architecture Level:

In the architecture, a service provider collects data from two phone applications. The "HealthXYZ" app sends the service provider a sickness record with an ip address (phone ip) other app, called, "SocialXYZ" also sends the social profile with the same ip address (same phone).

RECEIVE(sp,Sicknessrecord(nhsnumber,name,Meta(ip)))

RECEIVE(sp,Socprofile(photo,address,Meta(ip)))

The service provider is specified by a green box as main component, and the customer phone by a grey box.

Here we define the two messages spmessages1 and spmessages2.

As a result, we got that the service provider not only be able to link the data of types nhsnumber with the data of type photo, but it also has all the data of types nhsnumber, name, photo and address.

Example 3 (With Cryptographic Operations):

Here, the policy is the same as in the first example.

Architecture: The service provider, sp, receives the same data but with symmetric encryption (Senc), and it owns the decryption key for both messages.

RECEIVE(sp,Senc(Sicknessrecord(nhsnumber,name,Meta(ip)),spkey1))

RECEIVE(sp,Senc(Socprofile(photo,address,Meta(ip)),spkey2))

OWN(sp,spkey1)

The architectural actions are unchanged compared to example 2:

Here we only specify the ownership of one decryption key, namely, the content of the text box spowned in the figure above is OWN(sp,spkey1) .

As can be seen in the verification result below, sp will be able to decrypt both messages and link, have the data inside them. However, sp cannot have the data inside Socprofile from the socialXYZapp.

Check if an architecture is well-formed:

An architecture is well-formed e.g. if an entity/component can store or delete a piece of data, then the entity/component can receive, or own (calculate, create) that data. Furthermore, if an entity can use a piece of data, then an entity can receive, or own that data.

If we only define a STORE action without e.g. a corresponding RECEIVE action, then we get an error message that says the architecture is not well-formed.