Presentation

class: left, top
background-image: url(people.png)
background-size: 100%

#.solidbackground[Encryption, Anonymisation & Privacy Enhancing Technologies]

<div style="position: absolute; top: 90%">.solidbackground[.colour2[*Chris James*], 26 March 2024]</div>

???

---

# Who am I?

.big[
• Solicitor, qualified 2008

• General Counsel of a *fintech within a bank*

• Fellow and Chair of the Advisory Board of the Society for Computers & Law

• Former systems developer; technologist

• _Not_ a maths nerd 🙁

]

---

# Agenda

.big[
1.  .colour3[Encryption]

2.  .colour3[Anonymisation], and

3.  Other .colour3[Privacy Enhancing Techniques]
]

<!--

What I am trying to say - 
  
  is that debate around the role of data 
  is always enhanced by a solid understanding of technology generally,
  and of "privacy enhancing technologies" specifically.

I know this as a practicing lawyer.  This agenda is informed by those learnings that have actually been
  useful to me in my practice across several different clients, 
  and that I hope will be helpful to share with others.

I'm also conscious that, from experience, knowledge of these topics can vary quite greatly.
  I've tried to pitch this as "advanced beginner" if that isn't a contradiction, but let's see.

-->

---

.biggest.center[# 1. Encryption]

---

# 1. Encryption

### OECD:

.bigger.colour2["Encryption" means the transformation of data by the use of cryptography to produce unintelligible
data (encrypted data) to ensure its confidentiality.]

Source: OECD, <a href="https://legalinstruments.oecd.org/public/doc/115/115.en.pdf">Recommendation of the Council 
  concerning Guidelines for Cryptography Policy"</a>, 2022

---

# 1. Encryption

### Simple 'symmetric' encryption

.center[<img src="encryption1.png" alt="Encryption" width=80% />]

---
# 1. Encryption

### Asymmetric encryption / "public-key cryptography"

.center[<img src="encryption2.png" alt="Encryption" width=80% />]

---

# 1. Encryption

### PKI = Public Key Infrastructure

.center[<img src="encryption3.png" alt="Encryption" width=80% />]

---
# 1. Encryption

<div style="position: absolute; left: 50%; top: 80%;">.bigger[https://etc.ch/5qQg]</div>

<!-

How much web traffic is encrypted?

50%
70%
90% 
all of it

---
# 1. Encryption

.center[<img src="google_encrypted.png" alt="Graph of Google Chrome Encryption Stats" width=100% />]

Attribution: <a href="https://cloud.google.com/docs/security/encryption/default-encryption">Google</a>
---

# 1. Encryption in transit

* HTTPS uses .colour3["Transport Layer Security"]

* This *helps* protect the data .colour2["in transit"] (aka "in flight") against interception by a bad actor

---

# 1. Encryption in transit

* HTTPS uses .colour3["Transport Layer Security"]

* This *helps* protect the data .colour2["in transit"] (aka "in flight") against interception by a bad actor

.center[<img src="inflight.png" alt="Encryption in flight" width=80% />]

---
# 1. Encryption at rest

* Encryption ".colour2[at rest]", is also increasingly common.

.center[<img src="atrest.png" alt="Encryption at rest" width=80% />]

---

# 1. Encryption at rest

* Encryption ".colour2[at rest]", is also increasingly common.

* E.g. major cloud services:

* .small.colour3[Google]: .smaller["All data that is stored by Google is encrypted at the storage layer using the Advanced Encryption Standard (AES) algorithm ..."]

* .small.colour3[Amazon]: .smaller["Customers can control when data is decrypted, by whom, and under which conditions as it passed to and from their applications and AWS services."]

* .small.colour3[Microsoft]: .smaller["Data encryption at rest is available for services across the software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS) cloud models."]
---

# .center[#1. Encryption]

.big.center[Does .colour2["in transit"] + .colour2["at rest"]

a .colour3[privacy panacea?]]

---
# 1. Encryption

* Encrypted personal data is still personal data. (<a href="https://gdpr-info.eu/art-32-gdpr/">GDPR Art.32</a>).

* Encryption is a "technical measure" to protect data.

.colour2[_"<a hrEF="https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/encryption/">The ICO</a>
    has seen numerous incidents of personal data being subject to unauthorised or unlawful processing, loss, damage or destruction. 
    In many cases, the damage and distress caused by these incidents may have been reduced or even avoided had the personal data been encrypted."_]

---
# 1. Encryption

* Data is processed "in use" - and so processors usually need the keys

.center[<img src="encinfra.png" alt="Encryption in practice" width=80% />]

---
# 1. Encryption

* Data is processed "in use" - and so processors usually need the keys

* E.g. Data uploaded to providers is usually encrypted/decrypted there:

*  Providers usually manage the keys

* Therefore, providers have the data __and__ the keys

---

# Three .colour3[key] tricks for encryption

1. Use .colour2[state of the art] encryption technology

<!-- EDPB:

The protective capacity of cryptographic algorithms is subject to decline over time due to the discovery of new
cryptanalytic techniques, the emergence of new computing paradigms like quantum computing, and the general
increase of available computing power, unless the applied algorithms are proven to be information theoretically
secure

Source: https://edpb.europa.eu/system/files/2021-06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf

In practice - risk is more mundane - vulns.

-->

---
# Three .colour3[key] tricks for encryption

1. Use .colour2[state of the art] encryption technology

* Be careful to keep up with algorithmic advances

* Watch out for vulnerabilities

<!-- EDPB:

Source: https://edpb.europa.eu/system/files/2021-06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf

In practice - risk is more mundane - vulns.

-->

---
# Three .colour3[key] tricks for encryption

1. Use .colour2[state of the art] encryption technology

2. Consider .colour2[external key management] when using cloud

---
# Three .colour3[key] tricks for encryption

1. Use .colour2[state of the art] encryption technology 
   
2. Consider .colour2[external key management] when using cloud

* Keys held by you or trusted third parties, so only temporarily used by providers

* Complex to implement, may cause performance issues

---
# Three .colour3[key] tricks for encryption

1. Use .colour2[state of the art] encryption technology

2. Consider .colour2[external key management] when using cloud

3. Can you .colour2[go end-2-end?]

---
# Three .colour3[key] tricks for encryption

1. Use .colour2[state of the art] encryption technology

2. Consider .colour2[external key management] when using cloud

3. Can you .colour2[go end-2-end?]

* Type of encryption where keys never leave sender or recipient

* Good for untrusted environments e.g. payment terminals

* More complex for a lot of other situations

---

# e2e Encryption

3. Can you .colour2[go end-2-end?]

.center[<img src="e2e1.png" alt="Encryption in practice" width=80% />]

---

# e2e Encryption

3. Can you .colour2[go end-2-end?]

.center[<img src="e2e2.png" alt="Encryption in practice" width=80% />]

---

.biggest.center[# 2. Anonymisation]

---

# 2. Anonymisation

* Anonymisation is the process of taking personal data and making it: .small.colour2[“information which does not relate to
an identified or identifiable natural person or ... rendered anonymous in such
a manner that the data subject is not or no longer identifiable"]

---

# 2. Anonymisation

* We will cover:

* Anonymisation
  * K-Anonymity
  * Generalisation and suppression
  * Adversarial attacks

---

# 2. Anonymisation

* Is __not__ just removing the .colour3[obvious personal data]

---

# 2. Anonymisation

<div style="position: absolute; left: 50%; top: 80%;">.bigger[https://etc.ch/fmW2]</div>

<img src="https://etc.ch/fmW2/?qr" style="position: absolute; left: 80%; top: 0;" width=20% >
<div  style="position: absolute; left: 10%; top: 90%; font-size: x-small;"> Source:<a href="https://cpg.doc.ic.ac.uk/individual-risk/">Luc Rocher, Julien Hendrickx, and Yves-Alexandre de Montjoye. “Estimating the success of re-identifications in incomplete datasets using generative models.” Nature Communications 10 (2019) 3069.</a></div>

---

# 2. Anonymisation

* Is __not__ just removing the .colour3[obvious personal data]

* .colour3[Risk of re-identification] is inherent in most sets of personal data

<!--

"Researchers in Belgium, analyzed data on 1.5 million cellphone users 
   and found that just four points of reference, with fairly low spatial and temporal resolution, was enough to uniquely identify 95 percent of them.
    In other words, to extract the complete location information for a single person 
    all you would need to do is place him or her within a couple of hundred yards of a cellphone transmitter, 
    sometime over the course of an hour, four times in one year. "
    
-->

---

# 2. Anonymisation

* Is __not__ just removing the .colour3[obvious personal data]

* .colour3[Risk of re-identification] is inherent in most sets of personal data

* Measure using "K-Anonymity" or similar cluster method
  
  * Reduce identifiability through:
     * generalisation
     * suppression
---

# 2. Anonymisation

* K-Anonymity

" information for each person contained in the released table cannot be distinguished from at least 
k-1 individuals whose information also appears in the release"
<img src="kanon-table.png" width=100%>

---

# 2. Anonymisation

* .colour3[Approach:] Generalisation

<img src="generalise.svg" width=100%>
---

# 2. Anonymisation

* .colour3[Approach:] Suppression

---

# 2. Anonymisation

* Adversarial attacks .colour2[bolstered by AI]

* _ICO_: When anonymising, consider "all the means reasonably likely to be used, by
  yourself or a third party, to identify an individual that the information relates
  to"

* Artificial intelligence algorithms allow for "profiling attacks" using non-overlapping data

See further, <a href="https://dl.acm.org/doi/10.1145/3624010">Rigaki, Garcia (2023)</a>, <a href="https://ico.org.uk/media/about-the-ico/consultations/2619862/anonymisation-intro-and-first-chapter.pdf">ICO</a>
---

.biggest.center[# 3. Privacy Enhancing Technologies]

---

# 3. Privacy Enhancing Technologies

* Privacy Enhancing Technologies (.colour2["PETs"])

1. Pseudonymisation
 2. Hashing
 3. Differential privacy
 4. Synthetic data
 5. SMPC and Federated learning

---

# 3. PETs
## 1. Pseudonymisation

* Pseudonymisation is a word well-known in privacy circles - but may as well be 🤔⁉️🤔 to others
  
  * .smaller[Definition:]

.smallest[The processing of personal data in such
    a manner that the personal data can no
    longer be attributed to a specific data
    subject without the use of additional
    information, provided that such additional
    information is kept separately and is subject
    to technical and organisational measures
    to ensure that the personal data are not
    attributed to an identified or identifiable
    natural person’. This means that the use
    of ‘additional information’ can lead to the
    identification of the individuals, which is
    why pseudonymous personal data is still
    personal data.]
 
---

# 3. PETs
## 1. Pseudonymisation
   
   * Pseudonymisation is a word well-known in privacy circles - but may as well be 🤔⁉️🤔 to others
     
      
  * .smaller[Example:]
    <img src="pseudo.svg" width="90%">
    
   
---

# 3. PETs
## 2. Hashing

✅ Allows for pseudonymous (not anonymous) data sharing

<img src="hashing.svg" width="100%">
  
---

# 3. PETs
## 3. Differential privacy

✅ Adds noise to the data (.colour2["purturbing"])

⚖️ Balances privacy and data integrity

---

# 3. PETs
## 3. Differential privacy

* Best for statistical algorithms
.smallest["... an algorithm is said to be differentially private if by looking at the output, one cannot tell whether any individual's data 
was included in the original dataset or not. In other words, the guarantee of a differentially private algorithm is that its behavior
 hardly changes when a single individual joins or leaves the dataset -- anything the algorithm might output on a database containing
  some individual's information is almost as likely to have come from a database without that individual's information."]

.smallest[Credit: <a href="https://opendp.org/about#whatisdifferentialprivacy">OpenDP https://opendp.org/</a>]

---

# 3. PETs 
## 4. Synthetic data

* Creation of partially or wholly new data, statistically representative of original data

* Techniques: </br>
  .smaller[•.colour3[ redaction]: completely removing data from the dataset]<br/>
  .smaller[•.colour3[ replacing/masking]: replacing parts of the dataset]<br/>
  .smaller[•.colour3[ coarsening]: reducing the precision of the data]<br/>
  .smaller[•.colour3[ mimicking]: generate a dataset that closely matches the real dataset but does not contain exactly the same entries]<br/>
  .smaller[•.colour3[ simulation]: generating part or all of the dataset that is similar in essential ways to the real data but is different with regard to sensitive information]<br/>
.smallest[Credit: <a href="https://dataingovernment.blog.gov.uk/2020/08/20/synthetic-data-unlocking-the-power-of-data-and-skills-for-machine-learning/">Data in Government</a>]

---

# 3. PETs 
## 4. Synthetic data
  
* Creation of partially or wholly new data, statistically representative of original data
  
  <img src="synthetic.png" width="90%">

.smallest[Credit: <a href="https://dataingovernment.blog.gov.uk/2020/08/20/synthetic-data-unlocking-the-power-of-data-and-skills-for-machine-learning/">Data in Government</a>]
  
---

# 3. PETs
## 4. Synthetic data
  
<img style="display: block;-webkit-user-select: none;margin: auto;cursor: zoom-in;background-color: hsl(0, 0%, 90%);transition: background-color 300ms;" src="https://thispersondoesnotexist.com/" width="50%" height="50%">
.center[thispersondoesnotexist.com]

---
# 3. PETs
## 5. SMPC and Federated learning

* Secure Multiparty Computation (".colour3[SMPC]"):

.small["allows at least two different parties to jointly perform processing on
their combined data, without any party needing to share its all of its data
with each of the other parties.]

.small[All parties (or a subset of the parties) may
learn the result"]

.smallest[Credit: <a href="https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/privacy-enhancing-technologies/what-pets-are-there/secure-multiparty-computation-smpc/">ICO, Privacy Enhancing Technologies</a>]
---

# 3. PETs
## 5. SMPC and Federated learning

* Federated learning

.center[<img src="federated.png" width="50%">]

.smallest[Credit <a href="https://www2.deloitte.com/content/dam/Deloitte/it/Documents/risk/Federated-Learning-and-Decentralized-Data_Deloitte.pdf">Deloitte</a>]

---

# Emerging Privacy Enhancing Technologies

* Trusted execution environments

* Zero knowledge proofs

* Homomorphic encryption

---

# Emerging Privacy Enhancing Technologies

* Trusted execution environments

* Zero knowledge proofs

* Homomorphic encryption

<br/>

.center[<img src="he.png" width="80%">]

---

# Gotchas
## "I've been round the Wrekin and I've still not found the perfect solution"

* PETs are often:

* .colour2[Costly] - significant computing resources required
 * .colour2[Complex] - highly skilled engineers required
 * .colour2[Less accurate] - depending on technique
 * .colour2[Open to attack] (reconstruction, exfiltration etc.)

---

# 3. PETs

<div style="position: absolute; left: 50%; top: 85%;">.bigger[https://etc.ch/VY7B]</div>

---

# .center[My answer:]

.center[<img src="PETs.jpg" alt="SCL" width=35% />]

---

# .center[My answer:]

.center[<img src="PETs.jpg" alt="SCL" width=35% />]

.center["Good physical security protects against exfiltration attack"]

---
# Thank you

* Questions?

### Chris James

E-mail: mail@chrisjames.me.uk

<br />

<br />
.smallest[Cover image generated using Midjourney and available for use CC BY-NC-SA 4.0 DEED]