From fff2d20dc6bb95e5c3a11d49fa4a732d729a79ed Mon Sep 17 00:00:00 2001 From: HackMD Date: Thu, 30 Jun 2022 00:45:18 +0000 Subject: [PATCH 1/2] initial version --- UCAN keypair management.md | 58 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 UCAN keypair management.md diff --git a/UCAN keypair management.md b/UCAN keypair management.md new file mode 100644 index 00000000..e862be32 --- /dev/null +++ b/UCAN keypair management.md @@ -0,0 +1,58 @@ +# UCAN keypair management + + +### Problem statement + +Building services that use [UCAN][]s for authorization require that each service manage own keypair so it can interact with other service(s). Runnig many microservices implies having _many keypairs that need to be kept safe and secret_. + +Additionally cross service interaction e.g. service `did:key:zUpload` invoking `access/resolve` capability on service `did:key:zAccess` implies that: + +1. `did:key:zAccess` needs to issue UCAN that delagets "access/resolve" to `did:key:zUpload`. +2. `did:key:zUpload` need to keep delegated UCAN around in order to invoke `access/reslove`. +3. When `did:key:zAccess` rotates keys it's DID change needs to propagate thorugh dependencies and all the capabilities need to be re-issued. + + +It is easy to imagine this becoming a logistical nightmare with many interdependent services. + +:::info +In summary we want to keep service keypair very secure so we don't have to deal with logistics of updating DIDs and UCANs across all the services that interact with it. +::: + +### Thread model + +> It is important to do some [thread modeling](https://en.wikipedia.org/wiki/Threat_model) in deciding what solution would provide effective safeguard against these threats. + +#### Threat: Service key compromise + +Compromise service keypair would enable attacker to invoke capabilities on other services that were delegated to it before compromise is discovered. + +Our services heavily lean into content addressing and write only semantics. If all interations are also UCAN authenticated all the harm caused by compromised key could actually be undone on discovery. + +For that reason forced key rotation is arguably the most painful fallout of such an attack as it would require updating DIDs, issued UCANs across services and potentially in our user applications. + +#### Mitigation: Key custody + + +We could mitigate outlined thread by using a key custody service like [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/cryptographic-details/key-hierarchy.html) or [HashiCorp Vault](https://www.vaultproject.io/api-docs/secret/transit#hash-data). + +It is however important to consider tradeoffs: + +1. Signing invocations would require uploading UCAN invocations into key custody introducing extra latency. +2. Troubles in key custody service would have direct effect on our service operations. +3. All of our cross service interactions become observale by a key custody service (even when encrypted if they manage our keys). + +#### Migitaion: Secure supreme key + +Instead of services delegating capabilties to each other we could model our system differently in which we have a "supreme authority" that owns all the capabilities and delegates subset to a specific services that execute them. + +If designed this way service key rotation would barely affect others since UCANs would have been issued by "supreme authority" and not the service providing it. + +Only time "supreme authority" private key would be required is when we need to authorize new service or revoke capabilities of the compromised one. Given the low frequency of use such "supreme key" could live in secure hardware from which it can't be extracted. Furtherome we could adopt hardware key rotation. + +:::success +We could also consdier [BLS](https://en.wikipedia.org/wiki/BLS_digital_signature) and/or [Shamir's Secret Sharing](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing) schemes to account for hardware failures and resilience in cas of partial compromise. +::: + + + +[UCAN]:https://github.com/ucan-wg/spec/ \ No newline at end of file From 6c6e7ae254ea939021ff4be98bba597e288e1335 Mon Sep 17 00:00:00 2001 From: Irakli Gozalishvili Date: Thu, 30 Jun 2022 07:29:18 -0700 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: Vasco Santos Co-authored-by: Hugo Dias --- UCAN keypair management.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/UCAN keypair management.md b/UCAN keypair management.md index e862be32..032ee4b5 100644 --- a/UCAN keypair management.md +++ b/UCAN keypair management.md @@ -3,13 +3,13 @@ ### Problem statement -Building services that use [UCAN][]s for authorization require that each service manage own keypair so it can interact with other service(s). Runnig many microservices implies having _many keypairs that need to be kept safe and secret_. +Building services that use [UCAN][]s for authorization require that each service manage own keypair so it can interact with other service(s). Running many microservices implies having _many keypairs that need to be kept safe and secret_. Additionally cross service interaction e.g. service `did:key:zUpload` invoking `access/resolve` capability on service `did:key:zAccess` implies that: 1. `did:key:zAccess` needs to issue UCAN that delagets "access/resolve" to `did:key:zUpload`. -2. `did:key:zUpload` need to keep delegated UCAN around in order to invoke `access/reslove`. -3. When `did:key:zAccess` rotates keys it's DID change needs to propagate thorugh dependencies and all the capabilities need to be re-issued. +2. `did:key:zUpload` need to keep delegated UCAN around in order to invoke `access/resolve`. +3. When `did:key:zAccess` rotates keys it's DID change needs to propagate through dependencies and all the capabilities need to be re-issued. It is easy to imagine this becoming a logistical nightmare with many interdependent services. @@ -41,7 +41,7 @@ It is however important to consider tradeoffs: 2. Troubles in key custody service would have direct effect on our service operations. 3. All of our cross service interactions become observale by a key custody service (even when encrypted if they manage our keys). -#### Migitaion: Secure supreme key +#### Mitigation: Secure supreme key Instead of services delegating capabilties to each other we could model our system differently in which we have a "supreme authority" that owns all the capabilities and delegates subset to a specific services that execute them.