A Refinement Approach for the Reuse of Privacy Risk Analysis Results

Abstract

The objective of this paper is to improve the cost effectiveness of privacy impact assessments through (1) a more systematic approach, (2) a better integration with privacy by design and (3) enhanced reusability. We present a three-tier process including a generic privacy risk analysis depending on the specifications of the system and two refinements based on the architecture and the deployment context respectively. We illustrate our approach with the design of a biometric access control system.

Appendices

A Description of Phase 2 for Arch.1 and Arch.3

1.1 A.1 Arch.1: Use of an Encrypted Database

Description of Arch.1. In the simple biometric access control architecture pictured in Fig. 8, the server S stores the database of encrypted reference templates $\overline{ebr}$ and the access control rules ac. When the user presents his identity $ID_i$ and fresh biometric $rd_i$ to the terminal T, T fetches the encrypted reference template $\overline{ebr_{i}}$ from S, decrypts it using the key $k_{br}$ and compares $br_i$ with $bs_i$ produced from $rd_i$ by T (taking into account thr). The access control decision $dec_i$ is used to allow or deny access. The access logs $\overline{at}$ of different users are encrypted into $\overline{eat}$ and sent back by the terminal T at regular intervals to be stored in the server S. The access log $\overline{at}$ is updated after each access control.

The keys⁸ $k_{at}$ and $k_{br}$, the threshold thr and access control rules ac are persistently stored in the terminal T ⁹. In contrast, $\overline{at}$ is stored in T only for short time intervals. $dec_i$, $rd_i$, $bs_i$, $\overline{br_{i}}$, $ts_i$, $\overline{at}$, $\overline{eat}$, $\overline{ebr_{i}}$, $ID_i$ are deleted from the terminal T as soon as their use is over¹⁰.

The components in this architecture are therefore: the terminal T (C.1) and the server S (C.2).

Risk Sources for Arch.1. Since the architecture does not include any security components, we assume that no security operator is involved. The risk sources are therefore: the owner (A.1), cybercriminals (A.3), the state (A.4) and third parties (A.5). The owner (A.1) controls both the server S and the terminal T.

Personal Data for Arch.1 and Their Exploitability. At this stage, the privacy analyst presents each data element stored in each system component and its exploitability (see Table 7). As explained in Sect. 2, by “transient exploitation” of a component we mean exploitation for a short period of time or infrequent exploitation, (e.g., once in several months), whereas “persistent exploitation” means the exploitation of a component for a long period of time (e.g., for several days or months). For example, $dec_i$ provides the result of one access control for user i, whereas $\overline{at}$ provides the access log of all users for all previous days. So to know the access log of all users over t days, the risk source must either access all $dec_i$ for all users for each of the t days (persistent exploitation) or access $\overline{at}$ at the end of the t days (transient exploitation).

Table 7. Personal data in Arch.1 and their exploitability values

Refinement of Generic Harm Trees for Arch.1. In this phase, we consider the harm identity theft (H.2). Figure 9 shows the harm tree corresponding to this harm. Figure 12 in Appendix B shows how the generic harm tree (Fig. 2) for identity theft is pruned to obtain the architecture specific harm tree in Fig. 9. From Sect. A.1, we know that the risk sources for Arch.1 do not include A.2. Therefore, all branches of the generic harm tree for identity theft (H.2) that contain A.2 are pruned (pruned branches are marked by a red cross in Fig. 12). The definition of the architecture also makes it possible to instantiate the generic components $C_i$, $C_j$, $C_k$, $C_l$, $C_m$ and $C_n$.

Fig. 9.

Identity theft (H.2) harm tree for architecture Arch.1

1.2 A.2 Arch.3: Match-on-Card Technology

Description of Arch.3. Arch.2 is more protective than Arch.1 as the former uses a secure component M to perform the comparison between the fresh template and the reference template. In addition, it involves a security operator (A.2) for a better separation of responsibilities. However, in Arch.2, the fresh reference template $bs_i$ is still available in T along with $ID_i$. Moreover, the clear template $\overline{br_i}$ can still be accessed by the security operator (A.2) who controls M. In fact, A.2 has access to a lot of personal data. One way to overcome these difficulties is to use the match-on-card technology. In Arch.3, pictured in Fig. 10, each user possesses a smart card C that stores his identity $ID_i$ along with his enrolled template $br_i$ (i.e., it stores $\overline{br_i}$), the threshold thr and access control rules ac and performs the matching operation without disclosing $ID_i$ or $br_i$ to the terminal T. The owner does not store any database of reference templates.

The user inserts the card into the terminal T and submits the fresh biometric raw data $rd_i$. T derives a fresh template $bs_i$ from $rd_i$ and transfers it to C. C compares $bs_i$ with $br_i$ using the threshold thr and transfers the result of the access control $dec_i$ to T. T informs the user about $dec_i$ and sends it to the physical access control mechanism. The card C does not transfer any information apart from $dec_i$ (not even the user identity $ID_i$) to T. C is assumed to be completely secure (e.g., it is tamper-resistant and personalized by a certified issuer during the enrolment phase). Both $rd_i$ and $bs_i$ as well as $dec_i$ are deleted from T and C as soon as their uses are over. No access log $\overline{at}$ is recorded.

The system components in this architecture are: the terminal T (C.1) and the smart card C (C.4).

Risk Sources for Arch.3. We assume that there is no security operator (A.2) in this architecture, since the security relies only on the smart cards possessed by the users. Therefore, the risk sources to be considered include: the owner (A.1), cybercriminals (A.3), the state (A.4) and third parties (A.5). The owner (A.1) controls the terminal T.

Fig. 10.

Architecture Arch.3: Match-On-Card technology (Color figure online)

Table 8. Personal data in Arch.3 and their exploitability values

Personal Data and Their Exploitability for Arch.3. Table 8 presents each data item stored in each system component and the corresponding exploitability values for Arch.3. A risk source must have enough technical resources to exploit T persistently to get access to $dec_i$, $rd_i$ or $bs_i$. However, in contrast with Arch.1 and Arch.2, $ID_i$ is not stored in any component in Arch.3. Thus, in order to exploit $dec_i$ or $rd_i$, $bs_i$, risk sources must have $ID_i$ as background information. Since C is considered to be secure and belongs to the user, it does not appear in Table 8.

Refinement of Generic Harm Trees for Arch.3. Figure 15 in Appendix B shows how the generic harm tree for identity theft (H.2) (presented in Fig. 2) can be pruned to derive the corresponding harm tree for Arch.3 (presented in Fig. 11). In Arch.3, $ID_i$, $\overline{br_i}$, $\overline{ebr_i}$ and $k_{br}$ are not present at any moment in any of the components that the risk sources may access (i.e., terminal T). So all branches in the generic tree corresponding to these data elements are pruned. Also, the risk source A.2 is not a part of Arch.3. So all branches concerning A.2 are pruned too. The definition of the architecture also makes it possible to instantiate the generic components $C_i$, $C_j$, $C_k$, $C_l$, $C_m$ and $C_n$.

Fig. 11.

Identity theft (H.2) harm tree for architecture Arch.3

B Pruning of Harm Trees and Likelihood Computation for Identity Theft (H.2)

In this appendix, we present the harm trees for identity theft, showing in detail how branches of the generic tree are pruned based on different conditions (related to the architecture and the context) discussed in the paper.

Fig. 12.

Pruning of the generic harm tree for identity theft (H.2) to derive the harm tree for Arch.1 (Phase 2)

Fig. 13.

Identity theft (H.2) final harm tree for architecture Arch.1

Fig. 14.

Pruning of the generic harm tree for identity theft (H.2) to derive the harm tree for Arch.2 (Phase 2) (Color figure online)

Fig. 15.

Pruning of the generic harm tree for identity theft (H.2) to derive the harm tree specific to Arch.3 (Phase 2)

Fig. 16.

Final pruning of the harm tree for identity theft (H.2) for architecture Arch.3 (Phase 3)