From f0d19739491031db75da61ddbefa92a7856f488a Mon Sep 17 00:00:00 2001 From: Dan Yamamoto Date: Fri, 12 May 2023 06:51:45 +0000 Subject: [PATCH 01/13] Add privacy considerations --- spec/index.html | 249 +++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 247 insertions(+), 2 deletions(-) diff --git a/spec/index.html b/spec/index.html index 7e100ae..a7ae50d 100644 --- a/spec/index.html +++ b/spec/index.html @@ -2674,8 +2674,12 @@

Serialization

Privacy Considerations

-
-

Selective Disclosure Schemes

+

Privacy considerations here are primarily worth discussing when the canonicalization scheme is used for + privacy-respecting signed RDF dataset and are likely acceptable for other use cases. One of the former examples is a + verifiable credential with selective disclosure.

+ +
+

Data Leakage in Selective Disclosure Schemes

Add text that warns implementers using this specification in selective @@ -2686,8 +2690,249 @@

Selective Disclosure Schemes

which might be enough to disclose information beyond what the discloser intended to disclose.

+ +

Selective disclosure is the ability for someone to share only some of the statements from a signed dataset, without + harming the ability of the recipient to verify the authenticity of those selected statements.

+ +

The output of the canonicalization algorithm described in this specification, may leak partial + information about undisclosed statements and help the adversary correlate the original and disclosed datasets.

+ +
+

Possible Leakage via Canonical Labeling

+ +

If a dataset contains at least two blank nodes, the canonical labeling can be exploited to guess the undisclosed + quad in the dataset.

+ +

For example, let us assume we have the following dataset to be signed. (Note: this person is fictitious, prepared + only to make this example work.)

+ + 
+        
+
+ +

Using , we can obtain the serialized canonical form of the + normalized dataset, where all the blank nodes are serialized using the canonical labels.

+ + 
+        
+
+ +

The signer can generate a signature for the dataset by first hashing each statement and then signing them + using a multi-message digital signature scheme like BBS+. The resulting dataset with signature is passed to the + holder, who can control whether or not to disclose each statement while maintaining their verifiability.

+ +

Let us say that the holder wants to show her attributes except for `gender` to a verifier. Then the holder should + disclose the following partial dataset. (Note: proofs omitted here for brevity)

+ + 
+        
+
+ +

However, in this example, anyone can guess the unrevealed statement by exploiting the canonical labels and order.

+ +

Since the dataset was sorted in the canonical order, we can get to know that the hidden statement must start with + `_:c14n1 <http://schema.org/[f-g]`, which helps us guess that the hidden predicate is + `<http://schema.org/gender>` with high probability. Alternatively, we can assume that the guesser already has + such knowledge via the public credential schema.

+ +

Then, if the canonical labeling produces different results depending on the gender value, we can use it to deduce the + gender value. In fact, this example produces different results depending on whether the gender is `Female` or `Male`. + (Note: ignored the other types of gender just for brevity)

+ +

The following example shows that `gender` = `Male` yields different canonical labeling.

+ + 
+        
+
+ +

So the verifier should have obtained the following dataset if `gender` had the value `Male`, which differs from the + revealed dataset. Therefore, the verifier can conclude that the `gender` is `Female`.

+ + 
+        
+
+ +

Note that we can use the same approach to guess non-boolean values if the range of possible values is still a + reasonable (small) size for a guesser to try all the possibilities.

+ +

By making the canonicalization process private, we can prevent a brute-forcing attacker from trying to see the + labeling change by trying multiple possible attribute values. + For example, we can use a HMAC instead of a hash function in the canonicalization algorithm. Alternatively, we can add + a secret random nonce (always undisclosed) into the dataset. + Note that these workarounds force dataset issuers and holders to manage shared secrets securely. + We also note that these workarounds adversely affect the unlinkability described below because canonical labeling now + varies depending on the secret shared by the issuer and the holder, which will help correlate them.

+
+ +
+

Possible Leakage via Canonical Sorting

+ +

The canonical order can leak unrevealed information even without canonical labelings.

+ +

Let us assume that the holder has the following signed dataset, sorted in the canonical (code-point) order.

+ + 
+        
+
+ +

If the holder wants to hide the statement for their second child for any reason, the disclosed dataset now looks like + this:

+ + 
+        
+
+ +

Knowing that these statements are sorted in the canonical order, we can guess that the hidden statement must start + with `:a <http://schema.org/children> "Al`, which leaks the subject (`:a`), predicate + (`<http://schema.org/children>`) and the first two letters of the object (`"Al"`) in the hidden statement.

+ +

To avoid this leakage, the dataset issuer can randomly shuffle the normalized statements before signing and issuing + them to the holder, preventing others from guessing undisclosed information from the canonical order. + However, similar to the workarounds mentioned above, this workaround also adversely affects unlinkability. This is + because there are $n!$ different permutations for shuffling $n$ statements, and whichever one is used will help + correlate the dataset.

+
+
+

Unlinkability

+ +

Unlinkability ensures that no correlatable data are used in a signed dataset while still providing some level of + trust, the sufficiency of which must be determined by each verifier.

+ +

While canonical sorting works better for unlinkability, canonical labeling can be exploited to break it. + The total number of canonical labelings for a dataset with $n$ blank nodes is $n!$, which is not controllable by the + issuer. + It means that the herd constructed as a result of selective disclosure will be split into $n!$ pieces due to the + canonical labeling, which reduces unlinkability.

+ +

For example, let us assume that an employee of the small company "example.com" shows its employee ID dataset without + their name like this:

+ + 
+      
+
+ +

The verifier can always trace this person without knowing their name if this company has only three employees with + the following employee ID datasets.

+ + 
+      
+
+ + 
+      
+
+ + 
+      
+
+ +

The canonicalization in this example produces different labelings for these three employees, which helps anyone to + correlate their activities even if they do not reveal their names in the dataset.

+ +

By determining some "template" for each anonymous set (or herd) and fixing the canonical labeling and canonical order + used in the anonymous set, we can achieve a certain unlinkability.

+
From 73fe66c09a2295739ae7276c05aaf2c9f9b62d1e Mon Sep 17 00:00:00 2001 From: Dan Yamamoto Date: Fri, 12 May 2023 08:46:51 +0000 Subject: [PATCH 02/13] Fix section id --- spec/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/index.html b/spec/index.html index a7ae50d..98ff05f 100644 --- a/spec/index.html +++ b/spec/index.html @@ -2849,7 +2849,7 @@

Possible Leakage via Canonical Sorting

-
+

Unlinkability

Unlinkability ensures that no correlatable data are used in a signed dataset while still providing some level of From 5fcf4c2444eb4d5aa53805251771e95b972f23d0 Mon Sep 17 00:00:00 2001 From: Dan Yamamoto Date: Fri, 12 May 2023 08:48:55 +0000 Subject: [PATCH 03/13] Disable code highlights for N-Quads examples --- spec/index.html | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/spec/index.html b/spec/index.html index 98ff05f..338178c 100644 --- a/spec/index.html +++ b/spec/index.html @@ -2706,7 +2706,7 @@

Possible Leakage via Canonical Labeling

For example, let us assume we have the following dataset to be signed. (Note: this person is fictitious, prepared only to make this example work.)

- 
+      
         
     

 
-    
+    
       
     

 
-    
+    
       
       

 
-      
Using , we can obtain the serialized canonical form of the
+      
Using , we can obtain the serialized canonical form of the
           normalized dataset, where all the blank nodes are serialized using the canonical labels.

 
       

From 28b95e4a35d7f797dfe93ad6fa9e18260bb99cd2 Mon Sep 17 00:00:00 2001
From: Dan Yamamoto 
Date: Fri, 12 May 2023 09:11:53 +0000
Subject: [PATCH 05/13] Apply `example` class to the examples

---
 spec/index.html | 108 +++++++++++++++++++++++-------------------------
 1 file changed, 52 insertions(+), 56 deletions(-)

diff --git a/spec/index.html b/spec/index.html
index 7be2a28..02025dc 100644
--- a/spec/index.html
+++ b/spec/index.html
@@ -2706,9 +2706,8 @@ 
Possible Leakage via Canonical Labeling

       
For example, let us assume we have the following dataset to be signed. (Note: this person is fictitious, prepared
         only to make this example work.)

 
-      
+      
         
-    

+    
      
+      
+        
+      

 
-    
-      
-    

+      
+        
+      

 
-    
-      
+      
+        
+      

     

 
     
The canonicalization in this example produces different labelings for these three employees, which helps anyone to

From d68877abfc5e927a61ec1c6e95fa068014f1896e Mon Sep 17 00:00:00 2001
From: Dan Yamamoto 
Date: Fri, 12 May 2023 09:16:40 +0000
Subject: [PATCH 06/13] Fix nested `
`

---
 spec/index.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/spec/index.html b/spec/index.html
index 02025dc..e538ceb 100644
--- a/spec/index.html
+++ b/spec/index.html
@@ -2876,7 +2876,7 @@ 
Unlinkability

     
The verifier can always trace this person without knowing their name if this company has only three employees with
       the following employee ID datasets.

 
-    
      
+    

+    
 
     
The canonicalization in this example produces different labelings for these three employees, which helps anyone to
       correlate their activities even if they do not reveal their names in the dataset.


From 1688a91e9187c877f251b8bf09f266a681578f27 Mon Sep 17 00:00:00 2001
From: Dan Yamamoto 
Date: Fri, 12 May 2023 09:22:35 +0000
Subject: [PATCH 07/13] Fix unlinkability examples

---
 spec/index.html | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/spec/index.html b/spec/index.html
index e538ceb..b23d0d8 100644
--- a/spec/index.html
+++ b/spec/index.html
@@ -2876,10 +2876,11 @@ 
Unlinkability

     
The verifier can always trace this person without knowing their name if this company has only three employees with
       the following employee ID datasets.

 
-
@@ -2842,7 +2842,7 @@

Possible Leakage via Canonical Sorting

To avoid this leakage, the dataset issuer can randomly shuffle the normalized statements before signing and issuing them to the holder, preventing others from guessing undisclosed information from the canonical order. However, similar to the workarounds mentioned above, this workaround also adversely affects unlinkability. This is - because there are $n!$ different permutations for shuffling $n$ statements, and whichever one is used will help + because there are `n!` different permutations for shuffling `n` statements, and whichever one is used will help correlate the dataset.

@@ -2854,9 +2854,9 @@

Unlinkability

trust, the sufficiency of which must be determined by each verifier.

While canonical sorting works better for unlinkability, canonical labeling can be exploited to break it. - The total number of canonical labelings for a dataset with $n$ blank nodes is $n!$, which is not controllable by the + The total number of canonical labelings for a dataset with `n` blank nodes is `n!`, which is not controllable by the issuer. - It means that the herd constructed as a result of selective disclosure will be split into $n!$ pieces due to the + It means that the herd constructed as a result of selective disclosure will be split into `n!` pieces due to the canonical labeling, which reduces unlinkability.

For example, let us assume that an employee of the small company "example.com" shows its employee ID dataset without @@ -2931,7 +2931,7 @@

Unlinkability

correlate their activities even if they do not reveal their names in the dataset.

By determining some "template" for each anonymous set (or herd) and fixing the canonical labeling and canonical order - used in the anonymous set, we can achieve a certain unlinkability.

+ used in the anonymous set, we can achieve a certain level of unlinkability.

From 6f8cf64a416ab2c928f86e5d2f13f40ef24ce44e Mon Sep 17 00:00:00 2001 From: Dan Yamamoto Date: Wed, 17 May 2023 16:35:51 +0900 Subject: [PATCH 12/13] Apply suggestions from code review Co-authored-by: Ted Thibodeau Jr --- spec/index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spec/index.html b/spec/index.html index b5124dd..cea38e5 100644 --- a/spec/index.html +++ b/spec/index.html @@ -2758,7 +2758,7 @@

Possible Leakage via Canonical Labeling

However, in this example, anyone can guess the unrevealed statement by exploiting the canonical identifiers and order.

Since the dataset was sorted in the canonical order, we can get to know that the hidden statement must start with - `_:c14n1 <http://schema.org/[f-g]`, which helps us guess that the hidden predicate is, with high probability, + `_:c14n1 <http://schema.org/[f-g]`, which helps us guess with high probability that the hidden predicate is `<http://schema.org/gender>` . Alternatively, we can assume that the guesser already has such knowledge via the public credential schema.

@@ -2796,7 +2796,7 @@

Possible Leakage via Canonical Labeling

Note that we can use the same approach to guess non-boolean values if the range of possible values is still of a - reasonably small size for to try all the possibilities.

+ reasonably small size, allowing us to try all possibilities.

By making the canonicalization process private, we can prevent a brute-forcing attacker from trying to see the labeling change by trying multiple possible attribute values. From ae75903cccb3b7b0b1609dc39c9647eeafd319ee Mon Sep 17 00:00:00 2001 From: Dan Yamamoto Date: Fri, 19 May 2023 17:11:57 +0900 Subject: [PATCH 13/13] Apply suggestions from code review Co-authored-by: Ted Thibodeau Jr --- spec/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/index.html b/spec/index.html index cea38e5..3ba3ca0 100644 --- a/spec/index.html +++ b/spec/index.html @@ -2759,7 +2759,7 @@

Possible Leakage via Canonical Labeling

Since the dataset was sorted in the canonical order, we can get to know that the hidden statement must start with `_:c14n1 <http://schema.org/[f-g]`, which helps us guess with high probability that the hidden predicate is - `<http://schema.org/gender>` . Alternatively, we can assume that the guesser already has + `<http://schema.org/gender>`. Alternatively, we can assume that the guesser already has such knowledge via the public credential schema.

Then, if the canonical labeling produces different results depending on the gender value, we can use it to deduce the