From df46490e5f5788b91f0f09ac2699a1eb1d1a2628 Mon Sep 17 00:00:00 2001 From: Aurelia Date: Mon, 17 Jun 2024 16:23:19 +0200 Subject: [PATCH 1/3] Shamir deletion certificate rfc update. --- docs/rfcs/1000-shamir-based-recovery.md | 135 +++++++++++++++++++++++- 1 file changed, 132 insertions(+), 3 deletions(-) diff --git a/docs/rfcs/1000-shamir-based-recovery.md b/docs/rfcs/1000-shamir-based-recovery.md index 661dcb6ac98..8df167a5b56 100644 --- a/docs/rfcs/1000-shamir-based-recovery.md +++ b/docs/rfcs/1000-shamir-based-recovery.md @@ -87,7 +87,7 @@ To use the Shamir recovery: secret `SK` and decrypt `SK(alice@shamir1)`. 6) Alice uses `alice@shamir1` to re-create a new device (the recovered device). -## 1 - Create & update a Shamir recovery setup +## 1 - Create a Shamir recovery setup Authenticated API: @@ -102,8 +102,7 @@ Authenticated API: "fields": [ { "name": "setup", - // Set to `None` to clear previous Shamir recovery setup - "type": "RequiredOption" + "type": "ShamirRecoverySetup" } ] }, @@ -229,6 +228,8 @@ Consistency between `brief` and `shares` must be checked by the Parsec server: > organization-specific rules (e.g. the number of shares, the recipient's > profiles, max number of share per recipient, etc.). See "Bonus" section below. +To update the setup, the previous setup must be deleted first. + And the related certificates: ```json5 @@ -704,6 +705,121 @@ The claimer gets access to `reveal_token` and `data_key`, it can then retrieve ` Then `ciphered_data` can be decrypted with `data_key`. From then on, the recovery works just like the recovery device system (see `parsec core import_recovery_device` CLI). +## 4 - Delete a shamir setup + +Authenticated API: + +```json5 +[ + { + "major_versions": [ + 4 + ], + "req": { + "cmd": "shamir_recovery_deletion", + "fields": [ + { + "name": "certificate", + // Contains a ShamirRecoveryDeletionCertificate + "type": "bytes" + } + ] + }, + "reps": [ + { + "status": "ok" + }, + { + // Cannot deserialize data into the expected certificate + "status": "invalid_data" + }, + { + // Given timestamp does not match previous timestamps + "status": "incoherent_previous_timestamp" + } + { + // Nothing to delete + "status": "no_setup_to_delete" + }, + { + // Returned if the timestamp in the certificate is too far away compared + // to server clock. + "status": "timestamp_out_of_ballpark", + "fields": [ + { + "name": "ballpark_client_early_offset", + "type": "Float" + }, + { + "name": "ballpark_client_late_offset", + "type": "Float" + }, + { + "name": "server_timestamp", + "type": "DateTime" + }, + { + "name": "client_timestamp", + "type": "DateTime" + } + ] + }, + { + // Returned if another certificate or vlob in the server has a timestamp + // posterior or equal to our current one. + "status": "require_greater_timestamp", + "fields": [ + { + "name": "strictly_greater_than", + "type": "DateTime" + } + ] + } + ], + } +] +``` +The deletion certificate + +```json5 +{ + "label": "ShamirRecoveryDeletionCertificate", + "type": "shamir_recovery_deletion_certificate", + "other_fields": [ + { + "name": "author", + "type": "DeviceID" + }, + { + "name": "timestamp", + "type": "DateTime" + }, + { + "name": "previous_timestamp", + "type": "DateTime" + }, + { + "name": "share_recipients", + "type": "List" + } + ] +} +``` + +The certificate needs to include the previous certificate timestamp in the deletion certificateto link both certificates together. + +> Future evolution: link the certificates with 1/ the brief signature 2/ a certificate id. This kind of link can be done between the share and brief certificate too. + +Who need witch certificate ? + +| certificate | author | share recipient | +|-------------|--------|-----------------| +| brief | x | | +| share | | x | +| deletion | x | x | + + + ## Bonus ### **Future evolution 1**: Only Admin can clear Shamir recovery @@ -803,3 +919,16 @@ On the other hand, approach 1) allow things like "recovery requires Alice, Bob a requires Alice and Bob, or Adam alone". However given we cannot trust the server on such precise configuration, a new certificate type must be introduced which is cumbersome :( Also we should be able to provide approach 2) as part of approach 1). + +### **Future evolution 3**: notify shamir author when shamir secret become irrecoverable + +If Alice has setup a shamir with Bob, Mallory and John, each of then having one share and a threshold of two. +Then Bob and Mallory leave the organization. So this setup becomes unusable. + +The goal would be to have a notification to prompt the user to setup a new shamir. +Depending on the configuration, if any of the share recipient is deleted a warning could be sent first +event if the shamir could still be used. + +Two propositions could mitigate that: +- each time a user is deleted, if they were a share recipient a notification could be sent to users on the other end of this shamir setup. +- at each connection, check if share recipients are still valid. From 27453b513615e375e42445bef8d8a242f797b973 Mon Sep 17 00:00:00 2001 From: Aurelia Date: Thu, 20 Jun 2024 17:09:34 +0200 Subject: [PATCH 2/3] Typos. --- docs/rfcs/1000-shamir-based-recovery.md | 50 ++++--------------------- 1 file changed, 7 insertions(+), 43 deletions(-) diff --git a/docs/rfcs/1000-shamir-based-recovery.md b/docs/rfcs/1000-shamir-based-recovery.md index 8df167a5b56..f1d2912b6cd 100644 --- a/docs/rfcs/1000-shamir-based-recovery.md +++ b/docs/rfcs/1000-shamir-based-recovery.md @@ -139,7 +139,7 @@ Authenticated API: "status": "missing_share_for_recipient" }, { - // Future evolution 1: Shamir recovery has already been setup, should ask your admin to reset it first ! + // Shamir recovery has already been setup "status": "shamir_setup_already_exists" }, { @@ -224,7 +224,7 @@ Consistency between `brief` and `shares` must be checked by the Parsec server: - the recipients and their shares must be the same. - the certificates datetimes & authors must be the same. -> **_Future evolution 2:_** Check the Shamir recovery setup against some +> **_Future evolution 1:_** Check the Shamir recovery setup against some > organization-specific rules (e.g. the number of shares, the recipient's > profiles, max number of share per recipient, etc.). See "Bonus" section below. @@ -716,7 +716,7 @@ Authenticated API: 4 ], "req": { - "cmd": "shamir_recovery_deletion", + "cmd": "shamir_recovery_delete_setup", "fields": [ { "name": "certificate", @@ -735,11 +735,11 @@ Authenticated API: }, { // Given timestamp does not match previous timestamps - "status": "incoherent_previous_timestamp" + "status": "inconsistent_previous_timestamp" } { // Nothing to delete - "status": "no_setup_to_delete" + "status": "shamir_setup_not_found" }, { // Returned if the timestamp in the certificate is too far away compared @@ -806,9 +806,7 @@ The deletion certificate } ``` -The certificate needs to include the previous certificate timestamp in the deletion certificateto link both certificates together. - -> Future evolution: link the certificates with 1/ the brief signature 2/ a certificate id. This kind of link can be done between the share and brief certificate too. +The certificate needs to include the previous certificate timestamp in the deletion certificate to link both certificates together. Who need witch certificate ? @@ -822,41 +820,7 @@ Who need witch certificate ? ## Bonus -### **Future evolution 1**: Only Admin can clear Shamir recovery - -Authenticated API, `organization_config`: - -```json5 -[ - { - "major_versions": [ - 4 - ], - "req": { - "cmd": "organization_config" - }, - "reps": [ - { - "status": "ok", - "fields": [ - { - "name": "shamir_recovery_clear_strategy", - // Allowed values: - // - `ADMINS_ONLY` - // - `ADMINS_AND_SELF` - }, - // <------------ Already existing options omitted ---------> - ] - }, - { - "status": "not_found" - } - ] - } -] -``` - -### **Future evolution 2**: Specify a Shamir recovery setup template +### **Future evolution 1**: Specify a Shamir recovery setup template Shamir recovery allows plenty of different configurations (single recipient, different weight per recipient etc.), but we want to be able to set some limits here using the From 7bd5353bb966c8381a70b46c03d2530aaa8f9865 Mon Sep 17 00:00:00 2001 From: Aurelia Date: Mon, 24 Jun 2024 17:22:53 +0200 Subject: [PATCH 3/3] Shamir deletion rfc clean up. --- docs/rfcs/1000-shamir-based-recovery.md | 42 ++++++++++++++++++++----- 1 file changed, 34 insertions(+), 8 deletions(-) diff --git a/docs/rfcs/1000-shamir-based-recovery.md b/docs/rfcs/1000-shamir-based-recovery.md index f1d2912b6cd..28e1f7bb278 100644 --- a/docs/rfcs/1000-shamir-based-recovery.md +++ b/docs/rfcs/1000-shamir-based-recovery.md @@ -140,8 +140,9 @@ Authenticated API: }, { // Shamir recovery has already been setup - "status": "shamir_setup_already_exists" + "status": "shamir_setup_already_exists", }, + { // Returned if the timestamp in the certificate is too far away compared // to server clock. @@ -732,13 +733,24 @@ Authenticated API: { // Cannot deserialize data into the expected certificate "status": "invalid_data" + }, + { + // Share recipients lists are incoherent + "status": "incoherent_date" }, { - // Given timestamp does not match previous timestamps - "status": "inconsistent_previous_timestamp" - } + // There is already a deletion certificate for the same setup + "status": "shamir_setup_already_deleted", + "fields": [ + { + "name": "last_shamir_deletion_certificate_timestamp", + "type": "DateTime" + } + + ] + }, { - // Nothing to delete + // Nothing to delete, ie no setup was found with the same (author_user_id, timestamp) "status": "shamir_setup_not_found" }, { @@ -787,6 +799,7 @@ The deletion certificate "type": "shamir_recovery_deletion_certificate", "other_fields": [ { + // certificate author "name": "author", "type": "DeviceID" }, @@ -795,7 +808,13 @@ The deletion certificate "type": "DateTime" }, { - "name": "previous_timestamp", + "name": "setup_to_delete_timestamp", + "type": "DateTime" + }, + // User here must be the one owning the device used as author + // (i.e. a user can only remove its own Shamir recovery) + { + "name": "setup_to_delete_user_id", "type": "DateTime" }, { @@ -812,11 +831,18 @@ Who need witch certificate ? | certificate | author | share recipient | |-------------|--------|-----------------| -| brief | x | | +| brief | x | x | | share | | x | | deletion | x | x | +### How to decide if a deletion certificate is valid ? + +A setup can be identified by the tuple (author_user_id, timestamp) that we'll call shamir_id. +To decide is a deletion certificate is valid, the following questions must be asked +1. Is there a shamir setup with the corresponding shamir id ? No, means `shamir_setup_not_found` +2. Has this shamir id already a corresponding deletion certificate ? Yes, means `shamir_setup_already_deleted` +3. Is the share recipients list the same ? No, means `invalid_data` ## Bonus @@ -884,7 +910,7 @@ requires Alice and Bob, or Adam alone". However given we cannot trust the server on such precise configuration, a new certificate type must be introduced which is cumbersome :( Also we should be able to provide approach 2) as part of approach 1). -### **Future evolution 3**: notify shamir author when shamir secret become irrecoverable +### **Future evolution 2**: notify shamir author when shamir secret become irrecoverable If Alice has setup a shamir with Bob, Mallory and John, each of then having one share and a threshold of two. Then Bob and Mallory leave the organization. So this setup becomes unusable.