You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Add a deterministic recovery example
It uses the standard recovery example to recover its deterministic
secret, building on that with the steps required to recover the
deterministic data.
* Spelling/grammar pass
* Add blurb about running examples
Copy file name to clipboardExpand all lines: examples/disaster-recovery-example/README.md
+92-2Lines changed: 92 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,12 +17,14 @@ situations. 'Cause archeologists need love too!
17
17
18
18
This example uses previously encrypted data from the other examples. When run, it deconstructs that data and reconstitutes the original decrypted data.
19
19
20
-
The credentials to make running this yourself aren't provided, but you can see the code and example output for more information about what is happening.
20
+
The credentials to run this yourself aren't provided, but you can see the code and example output for more information about what is happening.
21
+
22
+
Information on IronCore document header shapes and protobuf formats can be found in the open-source [ironcore-documents](https://github.com/IronCoreLabs/ironcore-documents) repository.
21
23
22
24
## Recovery Process
23
25
24
26
### Retrieving the Encrypted Bytes, GCM tag, and IV
25
-
In the `EncryptedDocumentMap` (`Map<String, byte[]>`) returned by the TSC, the `byte[]`’s are of the structure:
27
+
In the `EncryptedDocumentMap` (`Map<String, byte[]>`) returned by the TSC, the `byte[]`s in v3 documents are of the structure:
26
28
27
29
```
28
30
VERSION_NUMBER (1 byte, fixed at 3)
@@ -36,6 +38,8 @@ GCM_TAG (16 bytes)
36
38
37
39
`ENCRYPTED_DATA` are the bytes you’ll be decrypting, and the `DATA_IV` is needed to make the AES decryption call. You’ll also need the encryption key, obtained in the next step.
38
40
41
+
See [ironcore-documents](https://github.com/IronCoreLabs/ironcore-documents) combined with the open-source code of the specific version of the TSC or IronCore Alloy that you're using to know what the document header structure of your data will be.
42
+
39
43
### Retrieving the Document Encryption Key
40
44
The DEK (Document Encryption Key) you need to decrypt the `ENCRYPTED_DATA` is the decrypted value of the EDEK (Encrypted DEK) that was also returned by the TSC.
You need to decode the EDEK base64 as an `EncryptedDeks` message, then for disaster recovery you're safe to just use the first `EncryptedDek` in the resulting list of them.
58
62
63
+
See [ironcore-documents](https://github.com/IronCoreLabs/ironcore-documents) combined with the open-source code of the specific version of the TSC or IronCore Alloy that you're using for the most up to date information on what protobuf formats to expect.
64
+
65
+
59
66
#### Un-leased
60
67
If the `EncryptedDek.leasedKeyId` is `0` (zero) you can decrypt the DEK by calling unwrap on your (or the tenant’s) KMS, passing the `EncryptedDek.encryptedDekData` bytes, using the correct credentials and key path. The result will be the DEK which can then be used in the “Decrypting the Document” step.
61
68
@@ -78,6 +85,9 @@ all known keypaths / creds and map out the associations.
78
85
79
86
80
87
## Example Run Output
88
+
89
+
Code for this process is in `src/index.ts`. It can be run with `yarn && yarn start` if you have IronCore GCP credentials. This same code could be modified or expanded on to work for your real data or recovery process, but it is not itself production quality code.
As mentioned in the [documentation on our website](https://ironcorelabs.com/docs/saas-shield/deterministic-encryption/#recovering-data) the recovery process for deterministically encrypted data requires a few extra steps. Deterministic data is encrypted with a key derived from a rotating tenant secret, which itself is wrapped by their KMS. To recover deterministic data, we need to:
117
+
118
+
1. Determine the ID of the secret used for our data.
119
+
2. Retrieve that previously backed-up encrypted secret.
120
+
3. Decrypt the secret (using the method described in [Recovery Process](#recovery-process)).
121
+
4. Use the secret to hash a string incorporating the derivation path and tenant ID.
122
+
5. Use that string as a key to decrypt the data.
123
+
124
+
Let's go over those steps in more detail. A concrete Typescript example of this process can be found in `examples/disaster-recovery-example/src/deterministic.ts`.
125
+
126
+
### Determine Secret ID
127
+
128
+
We need to retrieve the ID of the secret that was used to encrypt our piece of data so the encrypted secret can be retrieved from backups.
129
+
130
+
For deterministic data encrypted with the Tenant Security Clients (`tsc-java 6+`, `tsc-nodejs 3+`, not supported in `tsc-php` or `tsc-go`), the first 4 binary bytes contain the tenant secret ID, and the next two bytes are padding.
131
+
132
+
For deterministic data encrypted with IronCore Alloy, the first 4 binary bytes contain the tenant secret ID. See the [ironcore-alloy](https://github.com/IronCoreLabs/ironcore-alloy/blob/main/src/deterministic.rs) and [ironcore-documents](https://github.com/IronCoreLabs/ironcore-documents) source code for the most up-to-date information.
133
+
134
+
### Retrieve Secret
135
+
136
+
Encrypted tenant secrets are available from the Configuration Broker and should be regularly backed up.
137
+
138
+
In the UI a `.zip` of encrypted tenant secrets can be downloaded from the [Tenant Secrets page](https://config.staging.ironcorelabs.com/app/kms/secrets) of the Configuration Broker. Look for a clickable download icon near the page title.
139
+
140
+
In the Vendor API Bridge, a request to the [List Tenant Secrets](https://ironcore-labs.stoplight.io/docs/vendor-bridge/8ee4d2ba0dd9c-list-tenant-secrets) endpoint will return a `JSON` list of encrypted tenant secrets.
141
+
142
+
These encrypted secrets need to be backed up in a way that they can be reliably retrieved by secret ID in a disaster scenario.
143
+
144
+
### Decrypt Secret
145
+
146
+
The secret is encrypted by the tenant's KMS, and the process described in [Recovery Process](#recovery-process) is used to decrypt it. Notably, the secret will include a KMS config ID in its header (see [ironcore-documents](https://github.com/IronCoreLabs/ironcore-documents) for header formats), but without access to the Configuration Broker it won't be clear which of the tenants KMS key paths and credentials were referenced by that KMS config. In a true disaster scenario, you'll need to work with the tenant to either provide them with these secrets and have them try decryption with all their KMS keys, or have them provide you or your recovery tool with credentials that can access all their possible KMS keys to try.
147
+
148
+
### Create a Deterministic Key
149
+
150
+
Once you have the tenant's decrypted secret for this piece of data, you can create a deterministic key. Use the secret as a key to `HMAC-SHA512` sign over `"tenant_provided_id-derivation_path"`. The output of the hash is the deterministic key used to decrypt the actual data.
151
+
152
+
### Decrypt the Data
153
+
154
+
Use the deterministic key to `AES-SIV` decrypt the deterministic data. There is no `AES-SIV` associated data on IronCore deterministic values.
155
+
156
+
### Example Run Output
157
+
158
+
Code for this process is in `src/deterministic.ts`. It can be run with `yarn && yarn deterministic` if you have IronCore GCP credentials. This same code could be modified or expanded on to work for your real data or recovery process, but it is not itself production quality code.
0 commit comments